Subject: Re: [NDProxy#20] DHCPv4

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 08 Mar 2005 02:37:23 +0900

>>>>> On Sat, 19 Feb 2005 10:28:55 +0200, 
>>>>> Markku Savela <[email-masked]> said:

>> On Sat, 19 Feb 2005, Markku Savela wrote:
>> > This would work just fine, if nodes on internal network take the RA
>> > prefix length as is, and just trunctate their ID-parts from higher
>> > ends (or they could just generate ID randomly). Throw away all this
>> > sillyness with fixed 64-bit ID etc..
>> 
>> This would require changes to the hosts (and have other issues 
>> besides) -- not good.

> Implementations might already work this way.

Some implementations *might*, but I suspect most implementations
ignore such an "invalid" prefix on the contrary.  At least KAME/BSD
ignores it.

In fact, RFC2461 is already pretty clear that such a prefix MUST be
ignored:

       If the sum of the prefix length and interface identifier length
       does not equal 128 bits, the Prefix Information option MUST be
       ignored.  An implementation MAY wish to log a system management
(Section 5.5.3, bullet d).

rfc2462bis will even make this point clearer, with an attempt of
clarifying the consistency between the address architecture RFC and
link-specific RFCs wrt the appropriate prefix length.

Therefore,

> This should be specified
> in the RFC as a correct behaviour with longer prefix, instead of
> rejecting them.

I disagree.  "The RFC" (I'm not 100% which RFC you meant here though)
is already pretty clear on the "correct" behavior, which is strict on
the prefix length, and I don't see any reason to change this
requirement at this stage.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Mon, 7 Mar 2005 20:04:57 +0200

> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[email-masked]>
> 

Then, I suppose I will technically correct, if I just declare, that on
my own ethernet at home I can have identifier length = 56, and
announce prefix length = 72. It's local implementation issue. :-)

> link-specific RFCs wrt the appropriate prefix length.

Why do such limiting change? It only gives users more configuration
options. I don't mind it being by default 64+64, but it does not need
to be mandated.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 08 Mar 2005 09:44:08 +0900

>>>>> On Mon, 7 Mar 2005 20:04:57 +0200, 

> announce prefix length = 72. It's local implementation issue. :-)

I don't know how you came to that conclusion or whether you were just
joking...the appropriate prefix length (and thus the appropriate
interface identifier length) is specified as a link-specific constant
by the specification (RFCs), e.g, it's 64bits for ethernet links.  Thus,
"declaring the length is 56 bits" (whereas the standard constant is
different) is not a local implementation issue; such an implementation
is just non-compliant.

> options. I don't mind it being by default 64+64, but it does not need

I don't recall all past discussions, but there are always obvious
tradeoffs in this type of "flexibility" discussions:

- if we only use a fixed constant, we can avoid unexpected hazardous
  cases due to configuration error (e.g., very long prefix causing
  very likely address collisions).
- if we only use a fixed constant, the receiving side implementation
  can be simpler, in that it doesn't have to care about non-default
  cases.
- on the other hand, a fixed constant value decreases configuration
  flexibility

Since this is a matter of tradeoffs, opinions can always vary.  But in
my vague memory, we've discussed the tradeoff multiple times (perhaps
some directly and some implicitly), and somehow came to the consensus
with the fixed constant.  And, again, I don't think revisiting the
discussion at this stage is worth trying.

Of course, one can still make a separate new draft, proposing to relax
the constraint, if they think they can convince the community (I
personally won't support the document though:-)

					JINMEI, Tatuya