OK
It is certainly true that this is one of the things that is least likely to change.
Let's go with your latest update (in this mail)..
Reagrds,
elwyn
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 03 September 2004 11:21
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: new rev. of rfc2462bis will be coming
>
>
> >>>>> On Fri, 3 Sep 2004 11:57:36 +0200 ,
> >>>>> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>
> > Getting the wording right without creating double
> maintenance is a problem.
>
> > The point is that an address prefix only specifies the
> (prefix length) left
> > most bits. RFC3513 has examples with essentially arbitrary
> bits to the
> > right of the prefix. FE80::0/10 implies but does not make
> explicit what the
> > rest of the bits should be as well as putting back the
> double maintenance
> > thing.
>
> Okay, I see your first point. Regarding the double maintenance issue,
> I still think it's controversial. In addition to the points I raised
> in my previous message, we've already have several double-maintenance
> issues on the unicast link-local prefix: several RFCs has already
> hard-coded the concrete prefix of FE80::/10 or FE80::/64. To name a
> few:
>
> RFC2464, RFC2472, RFC2491, RFC2497, RFC2590, RFC3146 (IPv6
> over xxx links)
> RFC2529 (6over4)
> RFC2546 (6bone routing practice)
> RFC3315 (DHCPv6)
> ...
>
> and I'm quite sure several other I-Ds also hard-coding the concrete
> prefix.
>
> Will we really want to generalize the description for the existing
> RFCs when they are to be revised? Also, do we really want to
> "correct"
> all those I-Ds, before publication, not to hardcode the constant to
> avoid double maintenance problem? I don't think so. And if not, why
> is rfc2462bis so special?
>
> So,
>
> > How about:
>
> > A link-local address is formed by combining the well-known
> link-local prefix
> > [RFC3513] with the interface identifier as follows:
> ...
>
> the organization of the suggested text looks fine, but I'd still
> rather be concrete on the constant. And then the revised text would
> be as follows:
>
> =========================== from here
> =================================
> A link-local address is formed by combining the well-known link-local
> prefix FE80::0 [RFC3513] (of appropriate length) with the interface
> identifier as follows:
>
> 1. The left-most 'prefix length' bits of the address are the link
> local prefix
> 2. The bits in the address to the right of the link-local prefix are
> set to all zeroes
> 3. If the length of the interface identifier is N bits, the right-most
> N bits of the address are replaced by the interface identifier.
>
> If the sum of the prefix length and N is larger than 128 ...
> =========================== to here
> ===================================
>
> Can we live with this?
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center,
> Toshiba Corp.
> [EMAIL PROTECTED]
>
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
