Subject: RFC 2529 (6over4)

From: Sowmini Varadhan <[email-masked]>
Date: Tue, 3 Aug 1999 15:28:11 -0400 (EDT)

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. 

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".

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.

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".

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?

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.

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?

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?

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.

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?

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.

--------------------------------------------------------------------
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: Wed, 04 Aug 1999 11:58:06 +0200

In your previous mail you wrote:

   General comments

=> I implemented RFC 2529 some days ago then I read carefully the RFC
and I have not exactly the same idea about it.
 I think the basic idea is very clear, the site is considered as a large
LAN (named "virtual Ethernet" because >90% LANs are Ethernets), unicast
and multicast transmissions are done by unicast and multicast IPv4
routing inside the site using IPv6 over IPv4 standard stuff.
 Then there are only three details to specify:
 - interface ID (just use :0:0:x.y.z.t as usual)
 - IPv4 in link-layer info (use 0:0:x:y:z:t, another mapping like
   x:y:z:t:0:0 is possible but I have to recognize I prefer the RFC 2529 one)
 - IPv6 to IPv4 multicast mapping (the RFC proposal is reasonnable even
   there is no real rationate for the default TTL)
 I have implemented it as a virtual interface but I agree you have other
choices. In fact the only issue is if it is rather easy to translate
IPv6 multicast joins into IPv4, leaves are near impossible to translate
in BSD kernels. I have some parts of the initial FreeBSD work then I verified
this is a real issue and I picked up the name (*).

Regards

[email-masked]

PS: lines 297, 313 and 397: spelling errors
PPS: (*) a real problem because now I have 4 flavors of IPv6 over IPv4:
 - automatic tunnels (SIT)
 - configured tunnels (CTI)
 - 6 over 4 (VET)
 - 6 to 4 (STF) (a clone of SIT with less than 10% of diffs)
I'll add any other if you give to me both a spec and a name (:-)...
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Aug 1999 12:58:00 -0500

This point came up in 6to4 as well and it seems to vary quite
a bit between implementations. Personally I think referring to
virtual or pseudo interface makes the concepts much clearer,
but we probably need a phrase indicating that it is not
an implementation requirement.

Apart from that I think Cyndi has replied just about as I would
have done, if she hadn't got there first. Sowmini, do you think
there is any urgency to revise the RFC?

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [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: Erik Nordmark <[email-masked]>
Date: Thu, 19 Aug 1999 14:50:53 -0700 (PDT)

> an implementation requirement.

But we need to make sure we agree what that means.
For instance, the specification on source address selection
is likely to say "select among the addresses assigned to the interface ...".

I assume we want this to apply to the 6over4 or 6to4 interface, whether
or not it is implemented as a BSD ifnet structure.

Thus for clarity I suggest using the term "interface" as defined in RFC 2460
which includes attachments to a tunnel over IPv4.
But the document(s) should say that an implementation can provide the
specified behavior in any way it disires. 

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Aug 1999 14:42:46 -0700 (PDT)

>   122     fragment" bit MUST NOT be set in the encapsulating IPv4 header.

Since IPv4 path MTU discovery does not work for multicast packets
when sending an IPv4 multicast packet MUST NOT is correct.

When sendinfg IPv4 unicast packets I guess you can do IPv4 path MTU discovery
per IPv4 destination on the virtual 6over4 interface. I don't know if this
is worth the complexity - but RFC 1933 specifies how to do this on configured
tunnels and the logic would be the same.

   Erik