Subject: Re: RFC 2529 (6over4)

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 5 Aug 1999 10:17:40 -0400 (EDT)

>From [email-masked] Tue Aug  3 21:53:19 1999
>>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?

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.

>>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?

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

>>
>>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?

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.

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

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?

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

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
--------------------------------------------------------------------
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: Thu, 05 Aug 1999 17:04:52 -0500

Sowmini Varadhan wrote:
...
> depends on which is more widely implemented at the current time, I guess.

If we change this it is a change to the wire protocol and it invalidates
the existing implementations; it also means the document has to be
recycled at Proposed Standard. So we would have to be *very* sure
that we want to change it.

   Brian

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 06 Aug 1999 09:19:03 -0500

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

Let's see, you're talking about an inconsistency of debatable
importance between an RFC at PS status and an *expired* internet
draft; have I got it right?  Let me think about that for a
millisecond.

I've searched RFC's several different ways and can't find any other
which specify a source/target link-layer address option.

Can we move on now?
				Matt

---

From: Cyndi Jung <[email-masked]>
Date: Fri, 06 Aug 1999 11:46:51 -0700

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 05:04 PM 8/5/99 -0500, Brian E Carpenter wrote:
>> >>   199
+-------+-------+-------+-------+-------+-------+-------+-------+
>> >>   201
+-------+-------+-------+-------+-------+-------+-------+-------+
>> question becomes- "which spec needs to conform?". The answer to that
probably