Subject: Re: RFC 2529 (6over4)

From: Cyndi Jung <[email-masked]>
Date: Tue, 03 Aug 1999 18:39:35 -0700

Wow - I am delighted that you and your team have given it such a 
thorough review.

At 03:28 PM 8/3/99 -0400, Sowmini Varadhan wrote:
>
>
>Brian, Cyndi,
>
>We (the IPV6 team at Compaq) were looking at RFC 2529, "Transmission
>of IPv6 over IPv4 Domains without Explicit Tunnels", and had some 
>comments/questions that I have attached below.  Could you please
>review and clarify?
>
>Thanks in advance, 
>Sowmini
>
>-----------------------------------------------------------------------
>This is a summary of comments received from Jim Bound, Mary Clouter,
>Blaise Corcoran, Gerri Harter, Jack McCann, Yannick Pouffary, Ken Powell, 
>Sowmini Varadhan, Joe Vlcek, Eric Wong, and Vlad Yasevich, 
>
>General comments
>
>It would aid readability if the spec unambiguously clarified 
>the various steps leading up to the sending of a unicast packet on 
>a 6-over-4 net.  This could be done with an example  that traces 
>through some/all of the steps such as
>  - send out multicast neighbor-discovery packets 
>    using the methods described in Section 6 
>  - resolve the 6over4 link-layer address (defined in Section 5) 
>    of the next hop for the V6 destination 
>  - use this 6over4 link-layer address of the next hop  
>    as the V4 Destination address of the encapsulating header
>    (Figure xxx in Section 3) for unicast V6 packets. 

Since we modelled the draft directly from the RFC 2464, "Transmission
of IPv6 Packets over Ethernet Networks" where there is no such section,
we kept to that format except where comments from reviewers prompted
us to add information - such as section 7 for Scaling and Transition 
Issues and the Appendix A that describes how the solicited node multicast
addresses are constructed.

However, it can certainly be made more clear with an overview of the
concepts and the steps in the key goal of the mechanism.  I think this
overview would be better at the beginning, as a new section following
the Introduction, before the specifics of the mechanism are detailed,
rather than in another appendix.  The other choice is to leave this RFC
in the current terse style and provide the fuller description in an
applicability statement RFC - this approach would contribute towards the
progress of 6over4 as a standard, and since the text would be largely
descriptive rather than a change to the specification, it might be the
right direction to go with this - do you agree or not?

>
>It was not clear, when reading the spec, if the spec assumes that a
>node has "virtual interface" to the (virtual) 6over4 net, or does not
>make any such assumption.  
>
>Abstract ..  Section 1
>
>Since this is a technique to send IPV6 over IPV4 over foo,
>where foo may be something other than ethernet, should we 
>delete references to "virtual Ethernet" (line numbers listed below)?
>
>   42     IPv4 multicast as a "virtual Ethernet".
>   97     "6over4" and colloquially as "virtual Ethernet".

Both the "virtual interface" and the "virtual Ethernet" were terms
introduced into the text from the implementation project at UCLA on
the freeBSD platform.  They are useful conceptual aids, not codified
technical terms.  They have worked for some people, but they evidently
have not worked for you!

I personally don't believe that the RFC should dictate a "virtual 
interface", rather that the internal representation of this is 
specific to an implementation, and outside the reach of standardization.
If a MIB required somehow that an interface object exist to organize
the various bits of information associated with this "virtual interface",
then the term would become more solidly part of the spec.

As for "virtual Ethernet", I find that many people do make a hard link
between 6over4 and a physical Ethernet, which is not the intent.  The
use of the word "Ethernet" is to be evocative of the nice plug and play 
features that can be used on a multicast-capable subnet.  It is NOT to
imply that 6over4 is only good on LAN media.  

>
>Section 2
>
>It was not clear why the spec rules (lines below) that the 
>DF bit MUST NOT be set. Perhaps this injunction classifies as a "SHOULD NOT"?
>   121     ...  However, the IPv4 "do not
>   122     fragment" bit MUST NOT be set in the encapsulating IPv4 header.
>

In the region of an IPv4 network that supports a 6over4 IPv6 subnet there
may be IPv4 subnets with MTU smaller than Ethernet (we used the MTU of
the Ethernet as a reasonable default for the MTU on 6over4).  Even though
at the IPv6 level, Path MTU will yield a high value, that piece of IPv4
with the smaller MTU will be invisible to the IPv6 Path MTU.  Also, there
are tricks on IPv4 multi-link PPP that force fragmentation of IPv4 frames
to achieve a fairness (chop up FTP data frames so that smaller packets
can be interleaved amoungst the fragments of the larger frame, sort of
a mock-ATM strategy).  I'm sure there are plenty of other reasons why 
setting the DF bit would create difficult to detect failures - I personally
think the MUST NOT is right - how convinced are you that SHOULD NOT is 
right?

>Section 3
>
>The reference to the "datalink" header below is confusing, because it
>is not clear if the intended datalink refers to the IPV4 header or
>the physical (e.g., ethernet) link header. 
>   151     If there are IPv4 options, then padding SHOULD be added to the
IPv4
>   152     header such that the IPv6 header starts on a boundary that is a
32-
>   153     bit offset from the end of the datalink header.
>
>Unless it changes the intended meaning, it appears that it could
>be stated more directly as:
>  "If there are IPv4 options, then padding SHOULD be added to the IPv4
>   header such that the total size of the IPv4 header is a multiple of 
>   32 bits".

Actually, I think the paragraph is unnecessary, as the IPv4 header MUST
be padded to a multiple of 32 bits, as dictated by the IPv4 length field,
which expresses the number of 32-bit words in the IPv4 header :-)  Maybe
we should remove the paragraph since it is not only unnecessary but
confusing?

>
>
>Question about the recommended default value of the TTL field- is
>there a heuristic behind the suggested value of 8? (Is it approximately
1/2 the
>diameter of a standard network IGP site?)
>
>There appears to be a hierarchy in the various methods to contain
>6over4 multicasts within a site- specifically, it appears that TTL scoping
>becomes mandatory if administrative scoping (as described in RFC 2365)
>is not  supported in the site. Should the 6over4 spec emphasize this?

I think TTL scoping for multicast has been found to be unworkable - but
is still a poor man's scooping tool.  There is still work being done in
deploying the admin scoping, but I think the basic rules for the 
organization-local scope have been established.  Admittedly, establishing
the perimeter of a 6over4 subnet is central to the concept, and that
can usually be established with filters at the IPv4 level today, perhaps
with more sophisticated techniques later on.  This is probably appropriate 
material for that applicability statement.  Do you agree or not?

>
>
>Section 4
>
>See General comments regarding virtual interfaces to the 6over4 network- 
>does the "IPv4 virtual interface" in line 182 refer to 
>the virtual interface to the 6over4 network? If so, could the phrase
>"IPv4 virtual interface" be changed to "6over4 virtual interface"?
>
>If no assumptions are made about virtual interfaces to the 6over4 network,
>then the phrase should be left out.
>
>   182     The IPv6 Link-local address [AARCH] for an IPv4 virtual
interface is
>   183     formed by appending the Interface Identifier, as defined above, to
>   184     the prefix FE80::/64.
>

I agree - this section needs some work to better "suspend" the 6over4
interface above the (possibly) physical interfaces from which it borrows
an IPv4 address.  IPv4 is the subnet.

>Section 5
>
>The zero byte padding used in the link layer option is conflicting with
>the position of padding chosen in the only other document that I see 
>which attempts to define the format of Link-Layer address options.
>rfc2529 says:
>   198
>   199      +-------+-------+-------+-------+-------+-------+-------+-------+
>   200      | Type  |Length | must be zero  |        IPv4 Address           |
>   201      +-------+-------+-------+-------+-------+-------+-------+-------+
>   202
>while draft-conta-ipv6-trans-tunnel-00.txt says 
>                         0                   1
>                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                      0 |     Type      |    Length     |
>                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                      2 |             IPv4              |
>                        +-                             -+
>                      4 |           Address             |
>                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                      6 |          Padding              |
>                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>Should the 2 be consistent?

Do they need to be?  I can't find this draft, but I did find the
RFC2497 for shipping IPv6 over ARCNET, and the padding there is
post the media address.  I somehow think this is minor - is there
a need for consistency?

>
>Section 7
>Scaling issues: In a 6over4  network, each V6 multicast address
>potentially maps to a distinct V4 multicast group.  For example, 
>a node is required to compute and join the associated solicited-node
>multicast address for every unicast and anycast address it is assigned,
>and the the V4 multicast groups resulting from the 6over4 mapping
>could cause the multicast router at the site to handle over N 
>IPV4 multicast addresses, where N is the number of IPV6 hosts using  the
>6over4  network. However, paragraph 1 
>
>   252     The multicast mechanism described in Section 6 above appears to
have
>   253     essentially the same scaling properties as native IPv6 over most
>   254     media, except for the slight reduction in MTU size which will
>   255     slightly reduce bulk throughput...
>
>does not fully address this aspect..  is it really true that the 6over4 
>multicast mechanism, with dependancies on V4 multicasting, scales like 
>native IPV6?

Funny, I was worried about too many IPv6 addresses mapping to the same
IPv4 multicast address, since we were hashing into only 16 bits.  I
think it probably remains to be seen, though the 6over4 domains are
expected to be sparsely populated, and that the region each 6over4
domain subtends is not very large.  Usage will tell.  Also, this could
provide a metric for what is a reasonable size of IPv4 network region
to support a single 6over4 subnet.  I don't know that we can specify 
it from here - perhaps another section in that applicability statement.

It is not intended that there be one large 6over4 subnet that spans the
entire Internet.  It does not need to scale indefinitely - but it is
good to understand the limits of it's scalability.  The number of
multicast addresses created within the IPv4 organization-local scope is
one element that will determine the size to which a single 6over4 subnet
can scale, and that will largely depend on the size of the multicast
forwarding tables in the IPv4 routers.  The amount of traffic is 
negligible.  Most of the IPv4 multicast routers have ample space - they
claim.  The bigger concern I have is that there is talk about changing
the model for IPv4 multicast, since they seem to be getting nowhere in
the attempts to make interdomain multicast scale, and there is much
talk of single sender groups being the priority, and difficulty when
the sender does not already belong to the group (not on the distribution 
tree), because these groups of 6over4 are multiple-sender, and the 
sender is almost never also a receiver.

As for scaling, I think pushing ND over IPv4 multicast will be able to
take advantage of the IGMP snooping that is common now in LAN technologies.
So it will scale much better on modern LANs than ND running directly on'the
LAN.

>
>The ambivalency regarding assumptions about virtual interfaces to
>the 6over4 network led to some confusion about the interpretation
>of Section 7. (See General comments regarding virtual interfaces to 
>the 6over4 network) 
>
>If the spec does not (wish to) make any assumption about the presence of
>virtual interfaces to the 6over4 network, then it is not clear
>what sorts of tasks are implied by the "enabling" operation below:
>
>   264     ...  Interfaces of the IPv6 router and hosts
>   265     will of course need to be enabled in "6over4" mode.

I agree - the only interface is to IPv4.  The physcial interface
references is very misleading.  The point is that these interfaces
of IPv4 must be either included in the 6over4 subnet, or excluded,
and that has to do with the establishing the perimeter of the
administrative scoping multicast region.

>
>In the fourth paragraph, 
>
>   287     During transition, routers may need to advertise at least two IPv6
>   288     prefixes, one for the native LAN (e.g. Ethernet) and one for
>   289     "6over4".  As with any IPv6 prefix assigned to an IPv6 subnet, the
>   290     latter MUST be unique within its scope, whether site-local or
global
>   291     addressing is used.
>
>it would help if the need for two IPV6 prefixes was demonstrated with an 
>example. It was not clear when a router "may need" the 2 prefixes.  
>  - if no assumptions are made about having a separate virtual interface
>    to the 6over4 net, then it's not clear why/when the node would need 
>    2 prefixes.
>  - if, instead, the spec *does* assume that a node has a separate
>    virtual interface to the 6over4 net, then the requirement of unique
>    non-link-local addresses already mandates that the router must be 
>    advertising/using distinct IPv6 prefixes  for the native LAN and the 
>    6over4 network, so that the fourth paragraph is somewhat distracting
>    and redundant?

I agree - the 6over4 must really be disassociated from any physical
interface that IPv4 has - or that IPv6 has, for that matter.

>
>Similarly the "MUST" clause in the fifth paragraph could be clarified  
>by an example, or a detailed justification.
>
>   293     Also note that when a router is handling both native LAN and
"6over4"
>   294     on the same physical interface,  during stateless
autoconfiguration,
>   295     there is a period when IPv6 link-local addresses are used, in both
>   296     cases with the prefix FE80::/64. Note that the prefix-length for
>   297     these link-local adddress MUST then be 128 so that the two
cases can
>   298     be distinguished.

I have no sympathy for this clause either - I think it was heavily
influenced by the internals of the freeBSD implementation.  The
system within which I work would have no such problems, since the
incoming path is still knowable at the IPv6 level, so it is trivial
to distinguish IPv6 frames that come in on different interfaces even
though their IPv6 address is identical.

Cyndi
--------------------------------------------------------------------
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: GTECH-BR01 at GTECH-BEL-HUB <[email-masked]>
Date: Thu, 5 Aug 1999 17:10:00 -0400

>From [email-masked] Tue Aug  3 21:53:19 1999

IMHO  we need to establish a good reason ("prove") that the DF bit
must never, ever be set before we mandate it as a MUST NOT.

I can see that setting the DF bit has the  potential to
create dropped packets and  be inconvenient (and therefore SHOULD NOT be
set).
However, I don't see how this can create a gross error or disruption
of the network.  OTOH, there may be situations (e.g., tunnel PMTU)
that *do* require the DF bit to be set.

In addition, note that Section 7.2 of  RFC 2473 addresses the situation
when the DF bit is set on the IPV4 packet header, so this should allow
some method of failure detection.

>we should remove the paragraph since it is not only unnecessary but

I'd vote to have it removed, if/when the opportunity presents itself.

>>   199
+-------+-------+-------+-------+-------+-------+-------+-------+
>>   201
+-------+-------+-------+-------+-------+-------+-------+-------+
>post the media address.  I somehow think this is minor - is there

Yes, I think there's a need for consistency! Both configured tunnels
and the 6over4 conceptually use IPV4 as the link-layer, and there can
only be one kind of link-layer address for any particular link type, right?

Besides, I believe that it's cleaner from an implementation standpoint-
the implementation does not have to keep track of the type of
encapsulation (6over4 vs configured) when parsing incoming link-layer
address options.

If we all accept the premise that they should both be consistent, then the
question becomes- "which spec needs to conform?". The answer to that
probably
depends on which is more widely implemented at the current time, I guess.

>interface that IPv4 has - or that IPv6 has, for that matter.

Not sure what you agree with :-).. do you agree with "it's not clear
why/when the node would need 2 prefixes", or do you agree with "the
fourth paragraph is distracting etc."? I think either a clarification
or paragraph-deletion is called for here?

>though their IPv6 address is identical.

Good to hear that. We were all intrigued, esp. with the cross-referencing
between  Section 4 and the MUST clause above and were wondering if we were
missing something subtle here.

--Sowmini

---

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 6 Aug 1999 15:31:40 -0400 (EDT)

>From [email-masked] Fri Aug  6 15:21:43 1999
>
>I really can't understand why anyone would use ND or Redirects
>over a configured tunnel.  The Link-Layer address option is for ND
>and Redirects, isn't it?  Is there another use?
>
>Cyndi
>

At one point (about the same time last year), Cisco routers
were sending us link-layer address options with their router advertisements.
I'm not sure if they still do this.  I'm also not sure how useful it 
was intended to be, but we had to parse it all the same. --Sowmini

---

From: "ELAYOUBI, Issam" <[email-masked]>
Date: Sun, 8 Aug 1999 02:55:40 -0400

G'day all,

I'm not sure if you're referring to a routing protocol update, such as RIP,
OSPF, etc. or the Cisco Discovery Protocol (CDP) which operates at the Data
Link between Cisco equipment whether they are switches or routers. The
routing protocol don't advertise Link-Layer addresses, however, the CDP
does. Cisco provides mechanisms to turn-off that feature. Its usefulness is
to allow Cisco equipment to establish communication between each other for
management purposes and provides a mean of troubleshooting communication
links in the absence of a routing (Layer 3) protocol. Little overhead, yet a
powerful tool with controlled advertisement.

Cheers,

Issam.

-----Original Message-----
From: Sowmini Varadhan [mailto:[email-masked]]
Sent: Friday, August 06, 1999 3:32 PM
To: [email-masked]; [email-masked];
[email-masked]
Subject: Re: RFC 2529 (6over4)

---

From: Richard Draves <[email-masked]>
Date: Tue, 10 Aug 1999 21:31:37 -0700

> As far as implementations there is only one and I think its just a
> research effort?  But if its not I would be glad to be wrong.
> I know Francis is working on it now, and would really like to hear
> Francis's view on this too?

UCLA also has a working implementation for some BSD variant.

It would be good to hear from more implementors about this.

Rich

---

From: David Borman <[email-masked]>
Date: Wed, 11 Aug 1999 13:28:51 -0500 (CDT)

> Date: Wed, 11 Aug 1999 11:10:55 -0700
> From: Cyndi Jung <[email-masked]>
> Subject: RE: RFC 2529 (6over4)
> Cc: [email-masked]
> ...
> With only 64 bits of the Original Datagram Data, aka the IPv6 datagram,
> how is the ICMPv6 packet supposed to be delivered to the originating
> node?  Even if the originating node is the one to receive the ICMPv4
> message, there is not enough source IPv6 address in the packet for it
> to tell the message is for him, and certaily there is no destination
> IPv6 address to determine the node for whom the PMTU is less than the
> current assumed value of the linkMTU.
>
> Has there been an intervening spec that lengthens the data content of the
> ICMPv4 messages?  This is pretty old, yet there is no RFC that has
> obsoleted it, and it appears that the intent is to make sure the entire
> packet is small, ensuring that it will reach it's intended recipient.
>
> Now what?  Can we really use IPv4 PMTU?

Yes.  If the returned ICMPv4 Unreachable, Fragmentation Needed message
does not contain enough information to generate the ICMPv6 Packet Too
Big message, you just record the new MTU.  When the next 6over4 packet
comes along, you can then immediately generate the ICMPv6 Packet Too Big
message.

Please, everyone, if you haven't yet read section 6.1 "PMTU/DF Processing"
and Appendix B, "Analysis/Discussion of PMTU/DF/Fragmentation Issues" in
RFC 2401, please do so.  Then we can avoid rehashing issues that the
IPSec folks have already addressed, and concentrate on whether or not
there are issues unique to 6over4 that won't allow those schemes to work.

			-David Borman, [email-masked]

---

From: David Borman <[email-masked]>
Date: Wed, 11 Aug 1999 17:02:05 -0500 (CDT)

> Date: Wed, 11 Aug 1999 13:58:25 -0700
> >> In any case, the conclusion seems to be that one can imagine
> implementations
> >> that set the DF bit in the encapsulating v4 header. I don't see a reason
> for
> >> 6over4 to specify anything wrt DF bit.
> >
> >Yes, or at least, not outlaw it.
> >
> Does it need to give guidance on the use of PMTU, both at v4 and v6 levels?
> Or just be silent.

I'd say either just be silent about the DF bit, or make it a SHOULD NOT
and have a reference to RFC 2401, Section 6.1 and Appendix B.

> BTW, sending the ICMP Destination Unreachable message in V4 is optional -

Not really.  You aren't guaranteed that the ICMP message will get back
to you (just as you aren't guaranteed that any IP packet will get through),
but RFC 1812, "Requirements for IP Version 4 Routers", says:

  5.2.7.1 Destination Unreachable
     
     The ICMP Destination Unreachable message is sent by a router in  
     response to a packet which it cannot forward because the destination
     (or next hop) is unreachable or a service is unavailable.  Examples
     of such cases include a message addressed to a host which is not
     there and therefore does not respond to ARP requests, and messages
     addressed to network prefixes for which the router has no valid
     route.
     
     A router MUST be able to generate ICMP Destination Unreachable
     messages and SHOULD choose a response code that most closely matches
     the reason the message is being generated.

That doesn't sound very optional to me.  You can also look at RFC 1435.

BTW, the issue of only getting 64 bits of original header in the ICMP
message is also addressed in RFC 1812:

  4.3.2.3 Original Message Header
  
     Historically, every ICMP error message has included the Internet
     header and at least the first 8 data bytes of the datagram that
     triggered the error.  This is no longer adequate, due to the use of
     IP-in-IP tunneling and other technologies.  Therefore, the ICMP
     datagram SHOULD contain as much of the original datagram as possible
     without the length of the ICMP datagram exceeding 576 bytes.