Subject: About carring information in the next header value

From: <[email-masked]>
Date: Wed, 29 Oct 2003 20:40:38 +0100 (CET)

SIM uses two new next header values
The next header format for these two values is the same, since the 
different values are only 
used to encode the rewrite ok bit, is this correct?
Question, where is this next header placed in the chain of extension 
headers?
I guess that since routers must look for it when deciding whehter to 
rewrite or 
not a source address it would make it more efficient to place it in the 
first place, even before 
hop by hop options. But if this is so, wouldn't this be a problem to 
process hop by hop options?
The other options would be to place next to destination option header, 
where i guess is the 
right place for it, but in this case, the site exit routers would have 
to look over the 
extension header to find out whehter they should rewrite a source 
address or not.

The other issue with new extension headers is that host must discard 
unknown extension headers.
This may be a problem for the interaction between M6 hosts and legacy 
hosts, since the 
first packet would be discarded, and the way to find this out is the 
recpetiuon of icmp packet. 
Considering the potential wide deployment of ICMP filtering, this may 
lead to importat delay 
when establishing communications between m6 hosts and legacy hosts.

Perhaps an option would be to use a Destination option instead of an 
extension header.
This would allow to define the way the detination option would be 
processed by the legacy host, 
for instance, it can be defined that the host shoudl process the packet 
and just skip the 
unknown option. This would allow to process the initial packet and also 
to obtain a more 
reliable feedback of the capabilities of the target host.
The problem with this aproach is that it is not possible to encode the 
rewrite ok 
in the main IPv6 header using destiantion options. However, this could 
be encoded inside 
the destiantion option itself.
Note that if only the destiantion option is present in the packet, the 
bit encoding rewrite 
ok is in a fixed location and while it is not in the main ipv6 header, 
it should be easy to 
find by the exit routers, i guess.
If there are more extension headers in the packet, router will have to 
parse the extension 
header chain in both cases is guess, so i don't see much benefits in 
this case.

The other option is could be the following (i am not sure this would 
work though, i still don't
understand SIM very well:-(
Use a destiantion option in initial packets. If i understand correctly, 
initial packets 
are those whose source address cannot be rewritten. Also those iniotial 
packets are the one that
are used to define if the target node supports M6 or not
Then if the target node supports M6 and once that the context has been 
created, start using 
the new extension header. This extension header means that the rewrite 
ok bit is set.

So this option has most of the benefits i guess:
It allows the detection of M6 support at the target node without 
discarding the first packet and
obtaining a reliable answer (no icmp involved)
It allows a easy access to rewrite ok bit by the site exit routers when 
it is needed (not the inital 
packets)
It don't wastes two next header values

Anyway, i guess the most efficient option is the one presented in noid, 
that uses the nextheader 
and the flow label fields to carry the inforamtion in data packets.
I have a doubt about how the next header values are defined.
My first question is: do you define 2 values of next header for the  
every ulp protocol, 
covering the rewrite ok set and the rewrite ok not set, is this correct?
So you are not defining two values for the values of next header that 
define an extension header,
like routing header, hop by hop, etc. why is that, is becasue there are 
not enough next 
header values?
the problem with doing so, is that when an extension header is 
included, the site exit routers 
will have to parse all the extension headers until they find the ulp 
next header. Wouldn't this 
be a problem for efficiency? Perhaps this is not a very common case, 
though. 
Addtionally, I guess that you would like to preserve the values 
currently defined for ulp, at 
least fot compatibility with legacy hosts, but i am not sure if this is 
accomplished now as 
currently defined in section 6 of the noid doc.
I guess it would make more sense to define currently assigned ULP 
values to the case when 
the rewrite bit is not set, since legacy host would not recognize 
packets with modifed locators.

So my conclusion is that in order to ensure bacward compatibility and 
efficiency:
Initial packets should carry M6 information in a new destination option.
Initial packets carry next headers values for ULP as currenlty defined
following packets that use the M6 protocol carry the tag information in 
the flow label value and
encode the rewrite bit in newly defined ULP next header values (and no 
extension header)

Does this makes sense?
 
Thanks, marcelo

---

From: Juan Rodriguez Hervella <[email-masked]>
Date: Thu, 30 Oct 2003 10:33:14 +0100

On Wednesday 29 October 2003 20:40, [email-masked] wrote:

[snipped]

> covering the rewrite ok set and the rewrite ok not set, is this correct?

I think so, but only for the well-known UPL protocols and the others
are managed using a cuople of values + an extra extension header
which carries the actual UPL value.

> like routing header, hop by hop, etc. why is that, is becasue there are

I don't think so, I think that it is because it's only interesting to define
new values for the well-known upper layer values.

If you define new values for hop by hop, routing header, etc, routers already
in the market won't be able to process this new values and they will throw
away the packets.

> be a problem for efficiency? Perhaps this is not a very common case,

It's not going to be the common case, I agree with you. 
RFC 2460 specifies that:

"extension headers are not examined or processed
 by any node along a packet's delivery path, until the packet reaches
 the node"

There is an exception, the hop-by-hop header.

So I agree with you that this should be more elaborated. 

> least fot compatibility with legacy hosts, 

There is no compatibility problem with legacy host.

If hosts implement NOID, they will interact perfectly. On
the other hand, if a host doesn't implement NOID, it will
send and receive "normal" packets. It will send normal
packets because it doesn't know anything about NOID,
and it will receive normal packets because the peer
demultiplexes on wheter a packet is an M6 packet.

>but i am not sure if this is
> accomplished now as

That's not possible, because the new protocols values are
used for two reasons:

1. To still know what's up the IP layer (the normal use of the next protocol
field)

2. To know if the peer has NOID capabilities.

You can not find out if the peer knows about NOID when the
rewrite bit isn't set, if you use what you're telling.

[snipped]

Erik, I like your draft but I think this is useful once both
peers have already obtained the state. I don't know if somebody else
has asked you this, but I think this draft is weak on the stablishment
of the states, because until you aren't able to re-write, you still have
all the problems the muli6 WG is trying to solve.

Cheers!

-- 
JFRH

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 30 Oct 2003 14:56:39 +0100

I apologize for the format of this email (i was using a different email
client and things went wrong, sorry)
I send it again with a better format (i hope)
Regards, marcelo

SIM uses two new next header values
The next header format for these two values is the same, since the different
values are only used to encode the rewrite ok bit, is this correct?

Question, where is this next header placed in the chain of extension
headers?
I guess that since routers must look for it when deciding whehter to rewrite
or not a source address it would make it more efficient to place it in the
first place, even before hop by hop options. But if this is so, wouldn't
this be a problem to process hop by hop options?
The other options would be to place next to destination option header, where
i guess is the right place for it, but in this case, the site exit routers
would have to look over the extension header to find out whehter they should
rewrite a source  address or not.

The other issue with new extension headers is that host must discard unknown
extension headers.
This may be a problem for the interaction between M6 hosts and legacy hosts,
since the first packet would be discarded, and the way to find this out is
the recpetiuon of icmp packet.
Considering the potential wide deployment of ICMP filtering, this may lead
to importat delay when establishing communications between m6 hosts and
legacy hosts.

Perhaps an option would be to use a Destination option instead of an
extension header.
This would allow to define the way the detination option would be processed
by the legacy host, for instance, it can be defined that the host shoudl
process the packet and just skip the unknown option. This would allow to
process the initial packet and also to obtain a more reliable feedback of
the capabilities of the target host.
The problem with this aproach is that it is not possible to encode the
rewrite ok in the main IPv6 header using destiantion options. However, this
could be encoded inside the destiantion option itself.
Note that if only the destiantion option is present in the packet, the bit
encoding rewrite ok is in a fixed location and while it is not in the main
ipv6 header, it should be easy to find by the exit routers, i guess.
If there are more extension headers in the packet, router will have to parse
the extension
header chain in both cases is guess, so i don't see much benefits in this
case.

The other option is could be the following (i am not sure this would work
though, i still don't understand SIM very well:-(
Use a destiantion option in initial packets. If i understand correctly,
initial packets are those whose source address cannot be rewritten. Also
those iniotial packets are the one that are used to define if the target
node supports M6 or not
Then if the target node supports M6 and once that the context has been
created, start using the new extension header. This extension header means
that the rewrite ok bit is set.

So this option has most of the benefits i guess:
It allows the detection of M6 support at the target node without discarding
the first packet and obtaining a reliable answer (no icmp involved)
It allows a easy access to rewrite ok bit by the site exit routers when it
is needed (not the inital packets)
It don't wastes two next header values

Anyway, i guess the most efficient option is the one presented in noid, that
uses the nextheader and the flow label fields to carry the inforamtion in
data packets.
I have a doubt about how the next header values are defined.
My first question is: do you define 2 values of next header for the  every
ulp protocol, covering the rewrite ok set and the rewrite ok not set, is
this correct?
So you are not defining two values for the values of next header that define
an extension header, like routing header, hop by hop, etc. why is that, is
becasue there are  not enough next header values?
the problem with doing so, is that when an extension header is  included,
the site exit routers will have to parse all the extension headers until
they find the ulp  next header. Wouldn't this be a problem for efficiency?
Perhaps this is not a very common case, though.
 Addtionally, I guess that you would like to preserve the values  currently
defined for ulp, at least fot compatibility with legacy hosts, but i am not
sure if this is  accomplished now as  currently defined in section 6 of the
noid doc.
I guess it would make more sense to define currently assigned ULP values to
the case when the rewrite bit is not set, since legacy host would not
recognize packets with modifed locators.

So my conclusion is that in order to ensure bacward compatibility and
efficiency:
Initial packets should carry M6 information in a new destination option.
Initial packets carry next headers values for ULP as currenlty defined
following packets that use the M6 protocol carry the tag information in the
flow label value and encode the rewrite bit in newly defined ULP next header
values (and no  extension header)

Does this makes sense?

Thanks, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 31 Oct 2003 13:20:33 +0100 (CET)

> used to encode the rewrite ok bit, is this correct?

That is what the draft says. But in SIM the "no rewrite" value might only be
needed for the "no context" error message (to ensure that the locators
used in the error match the locators in the offending packet).
And it might even be possible to avoid this.

> Question, where is this next header placed in the chain of extension 

The draft says immediately after any hbh or routing header.

For compability with existing IPv6 routers I don't see how the header
can be placed before those headers.

> hosts,

Not an issue as the draft is written. Only destinations which have one of
the new "ID" records in the DNS would receive M6 headers.
And for the responding end which didn't do a DNS lookup, it will
only send M6 packets if it has received an M6 packet from the peer.

> covering the rewrite ok set and the rewrite ok not set, is this correct?

Two for each common protocol that is likely to benefit from/use multihoming
support.

> be a problem for efficiency? Perhaps this is not a very common case, 

Folks can argue whether such inefficiency is better or worse than the
inefficiency in SIM of including an extra 8 byte header in every packet.
That is one piece of the tradeoffs.

> currently defined in section 6 of the noid doc.

NOID doesn't redefine e.g. the nexthdr value for TCP.
It does define two new values for
	TCP over M6 with rewrite ok
	TCP over M6 without rewrite ok

> packets with modifed locators.

That isn't sufficient since you need to carry not only the "rewrite ok"
logical bit in the packet but also the "packet is using M6".
Thus to encode this in the nexthdr field you need the existing
protocol number assignment plus two more values for each common protocol.

> Initial packets should carry M6 information in a new destination option.

Makes no sense to me since there is another mechanism to tell whether
the peer supports M6 - the DNS record.

> encode the rewrite bit in newly defined ULP next header values (and no 

That doesn't tell the receiver whether the sender supports the M6 protocol.
Thus the receiver would end up triggering M6 processing (sending
a context request in NOID etc) even if the sender doesn't support M6.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 31 Oct 2003 13:57:15 +0100 (CET)

> Erik, I like your draft 

which one of the four :-)

> but I think this is useful once both

Not so because the behavior is transparent to the ULP.
Thus the ULP is operating using some AID and underneath it the M6 layer
will, until state has been establishes, try different locators for the peer.

In NOID and CB64 there are probably some scenarious related to locator failures
that need some more thought (and the specifications don't state which end is
responsible for retransmitting). In SIM (or any approach which has the
initiator explicitly starting the context creation exchange) I think locator
rewriting can be enabled during that exchange, with perhaps the need for a
challenge if the locators actually change during the exchange.

FWIW the optimization to not perform the challenge immediately when
a host-pair context is created does add some complications.
But I think this optimization is important to not incur public key
operations for every context that is created.

   Erik