The current draft states that a non-zero label could be changed by an
intermediate node to a non-zero value. However, during the discussion on the
topic in SLC it was concluded (IMO) that this is undesirable, and it would
be more useful (and sound) to keep the value always immutable (end-to-end).
Then about the text about allowing changes if the value is preserved
end-to-end. I agree it is kind of weird, but the intention was to say that
if you really, really want to do label switching of any sort, you'll need to
pay the price of being able to restore the original value before going out
of a network doing such things. This was put in there to make this point. I
agree that networks in general can and do modify packet contents in transit
(e.g. header compression), but normally this happens below the IP layer
(e.g. the link layer).
AH: It could be possible to change AH, but it might not be worth it. The
main problem would be the interoperability problem between a source sending
non-zero flow label and including it in the AH computation, and an old
destination receiving it and replacing 0's for the Flow Label for AH check
(which would fail). But is this important? Could we just ignore AH? (Who is
using it anyway?)
Jarno
> -----Original Message-----
> From: ext Robert Elz [mailto:[EMAIL PROTECTED]]
> Sent: 19. joulukuuta 2001 13:25
> To: Brian E Carpenter
> Cc: [EMAIL PROTECTED]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt
>
>
> Date: Wed, 19 Dec 2001 11:37:55 +0100
> From: Brian E Carpenter <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> | We can note the discrepancy, but I doubt if we can change
> | IPSEC at this point in time.
>
> We wouldn't want to anyway. The draft doesn't make the
> field immutable,
> it just makes it usually immutable. If it was 0 at the
> source, then it is
> mutable, and if the host has told some router(s) that it is
> OK to alter it,
> it is mutable as well.
>
> Attempting to have IPSec deal with that would be silly.
>
> So, it is possible for routers to alter it, undetectably to
> the receiver.
> (Or unless copy of what it should be has been sent via other methods,
> which it very well might be if there's been some flow setup done - the
> receiver might even have told the senders what value to use if this a
> multicast session set up via sd or similar).
>
> That it is possible however doesn't mean that we can't tell them they
> must not - just as well tell them they must not increment the
> hop limit.
> If they do, there's no way for the receiver to know, so a
> router could.
> But it must not - it must decrement it instead.
>
> kre
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
