Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt

From: [email-masked]
Date: Wed, 19 Dec 2001 17:18:19 +0200

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-masked]]
> Sent: 19. joulukuuta 2001 13:25
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt 
> 
> 
>     Date:        Wed, 19 Dec 2001 11:37:55 +0100
>     From:        Brian E Carpenter <[email-masked]>
>     Message-ID:  <[email-masked]>
> 
>   | 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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 09:53:36 +0100

In your previous mail you wrote:

=> I disagree: if the end node is too dumb to set itself the label
(i.e. just uses in any case the zero value) and the first router
for instance sets the label when needed then the zero value should
not be immutable. I don't use dumb hosts (:-) but it seems this kind of
things already commonly happens for RSVP in the real world so we should
keep the door open... So I fully share Robert Elz's opinion.

   AH: It could be possible to change AH, but it might not be worth it.

=> Robert Elz has just explained why we must not change AH...
And it seems you don't understand that AH can't really help to protect
something in transit, i.e. intermediate routers have not the key and
can't verify the AH MAC.

Regards

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2001 11:18:50 +0100

[email-masked] wrote:
> of a network doing such things. 

When I think about it, it makes no sense. The only way to restore the original
value is if you carry it with the packet (nothing else is safe). That means
adding a shim header. If you're going to add a shim header, you might as well
use it for the label switching anyway, so there is simply no point in ever
using the IPv6 label for label switching.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 Dec 2001 18:25:13 +0700

Date:        Thu, 20 Dec 2001 11:18:50 +0100
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | The only way to restore the original
  | value is if you carry it with the packet (nothing else is safe).

I'm not sure that is true.   To take a (very stupid I admit) counter
example.   A service provider might simply refuse to carry any traffic
with an odd flow id (they can throw away traffic for any reason they
like after all...).   So, they know that the only packets that survive
entry filtering have an even flow id.  Then they could use the lsb of
the flow id as some kind of signalling device inside the network.
Upon exit, the lsb of the flow id can be unilaterally cleared.

More likely, an ISP might arrange to use (internally) a certain flow ID
to get a specified service class.  When a new flow for a particular
destination arrives, that requests that service class, they could send
notification to the destination of the original flow id, and the one
that will be used instead.  Then for the rest of the flow, packets get
modified to use the internal flow id, with the exit router using the 
pre-determined original flow ID to replace the one that was used internally.
This needs frills to be able to deal with multiple flows with the same
service class to the same destination but that's manageable (perhaps not
nice, but manageable).

So I'm not sure it is quite true to say that it would never make sense
for an ISP to do this (including putting the label back on exit) - but
as long as the label received is the same as the label transmitted,
there's no way to tell what is going on inside there, nor is there
any reason for anyone to care.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2001 13:30:20 +0100

Robert Elz wrote:
...
> any reason for anyone to care.

I won't argue the point (I think I can prove my assertion that a shim
is the only safe solution, but the margin of this email is too small:).
In practice we agree: the document should say that the flow label
delivered to the destination must be identical to that set at the source.
It's redundant to say any more.

  Brian

---

From: Michael Thomas <[email-masked]>
Date: Thu, 20 Dec 2001 10:09:53 -0800 (PST)

> keep the door open... So I fully share Robert Elz's opinion.

   I'm afraid this brings us back to the slippery slope
   of edge-remarkers and the layer violation of routers
   wanting to look at L4+ headers, and the inherent 
   difficulty/impossibility. Please, let's not go there
   again.

 > something in transit, i.e. intermediate routers have not the key and

   If there's a change that will happen to AH it will
   be moving it to Historic.

	     Mike

---

From: Alex Conta <[email-masked]>
Date: Thu, 20 Dec 2001 19:37:07 -0500

The flow label, as defined in the draft, eliminates the need of
infrastructure devices to snoop at transport (end-to-end) headers. This
is a big achievement: after all, the Network should not
process anything beyond the network headers.

Host-to-host headers are for processing at source and destination. IPv6
is so generous that it gives us the Destination Options, if we want
end-to-end in network layer headers. Final destination hosts will
process anyway IPv6 Destination Headers, and transport (host-to-host, or
end-to-end) headers. Those headers can carry anything that a source host
may mean to send to the final destination, with no touching by
forwarding engines. 

Not to be misunderstood: I am not against end-nodes using the flow
label. But that use should mold onto, or piggy-back on a use, or onto a
definition that favors or is important to the Network. It would be wrong
to do it the other way around, that is to have the flow label use in the
Network, piggy-back on host-to-host functions, or definition.

So, I think we should be careful and not go too far, with an end-to-end
emphasis, that is,  restricting the flow label just because of the
possible end-node use, to the detriment of possible use in Network
(infrastructure) devices. This philosophy guided the original definition
of the flow label, reflected in the AH definition, and I agreed then and
I agree now with it.

Regards,
Alex

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 21 Dec 2001 08:26:11 -0600

Just a reminder, people claim that 80% of all IP-based equipment
is never connected directly to "THE Internet"....whatever THE is...

Jim Fleming
http://www.RepliGate.net

----- Original Message ----- 
From: "Francis Dupont" <[email-masked]>
To: "Michael Thomas" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, December 21, 2001 8:03 AM
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt 

>       difficulty/impossibility.
> 
> => I agree I don't like this but this is a fact.
> BTW if the XXXServ is not for free, I am afraid that
> this (and similar tools like security gateways) is needed
> in order to keep a reasonable control...
> 
>       Please, let's not go there again.
>    
> => I may not throw away a vendor of a well-known router company
> when he proposes to use a "transparent proxy"... Until all boxes
> will be NextToComeServ capable as my BSD boxes, we have to
> bear far worse than managing XXXServ or/and any other advanced
> function at the first router.
> 
> Regards
> 
> PS: AH is useful, for instance if AH was used with all the tunneling
> stuff under FUD in another thread of this list, the answer would be
> so simple!

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 15:03:57 +0100

Regards