Subject: (ngtrans) diff-serv comment 1 on transition mechanisms

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 Apr 1999 13:37:48 -0700 (PDT)

>----------------Begin Forwarded Message----------------<

Date: Fri, 9 Apr 1999 11:05:38 -0400 
From: "Black, David" <[email-masked]>
Subject: RE: ECN: Tunnel/SA relationship 
To: "'Jun-ichiro itojun Hagino'" <[email-masked]>, "Black, David"
<[email-masked]>, [email-masked] Cc: [email-masked],
"[email-masked]'" <[email-masked]>

>	Another thing: do you have any recommendation to IPv6 over IPv4
>	tunnels from ECN perspective?  There are so many of these for 6bone
>	(see www.6bone.net) and I'm hoping IPv6 network to be a good
>	playground for ECN related items.  Most of IPv6-over-IPv4 tunnels
are
>	based on RFC1933.  To summarize:
>		ingress: set TOS to 0
>		egress: drop IPv4 header

For the long term, proverbial "right thing to do" solution,
the diffserv header RFC (2474) has simplified things by
unifying the IPv6 Class and IPv4 TOS fields -- they now have
the same format, and are called the DS Field.  If security concerns
are not involved (should be the case for the 6bone), the right
thing to do is copy the DS Field out to the IPv4 header on
ingress and copy it back to the IPv6 header on egress.  For
backwards compatibility (e.g., what happens if a new egress
implementation is mixed with an old ingress implementation)
it's probably a good idea to check for a DSCP value of 0
on egress and not copy the DSCP to the v6 header if that's
found to avoid clobbering the v6 DSCP if the v4 DSCP was set
to zero on ingress - instead just copy back the last two
bits that ECN uses.

In practice, there's a lot of older equipment out there, and
hence some care is in order to avoid clashes between the
traditional IPv6 vs. IPv4 uses of these fields.  For a v6 over
v4 tunnel, the major concern is the resulting v4 value of what
used to be called IP Precedence (3 most significant bits of TOS
- see RFC 2474), and in particular traffic for which those bits
have the value 11x, as v4 has traditionally used these for routing
traffic that needs priority when the going gets rough.  Other
non-zero values may be of concern to some network operators.
A reasonable thing to do on ingress is check for values that will
cause concern/problems, and set the v4 DSCP to zero (still
copying out the two ECN bits).  The egress check in the previous
paragraph then does the right thing.  An even better situation
would be that v6 sources never use "class" values that cause
these problems (I don't know enough about IPv6 usage to know
whether that's the case or not), in which case this check is
not needed.

In any case, care needs to be taken not to mix new
and old implementations on the two ends of the same tunnel,
as the result in both cases is potential erasure of ECN
congestion notifications (either by discarding the notification
in the outer v4 header, or by zeroing the notification in
the v6 header).  I would hope that we don't need to introduce
a negotiation protocol for this purpose (aside from email and/or
the telephone).

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------

>----------------End Forwarded Message----------------<