Subject: Re: I-D ACTION:draft-lutchann-ipv6-delegate-option-00.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Feb 2002 13:03:40 +0200 (EET)

On Thu, 21 Feb 2002 [email-masked] wrote:
> 
> 
> 	Title		: IPv6 Router Advertisement Prefix Delegation Option
> 	Author(s)	: N. Lutchansky
> 	Filename	: draft-lutchann-ipv6-delegate-option-00.txt
> 	Pages		: 
> 	Date		: 20-Feb-02
> 	
> This document defines the Prefix Delegation (PD) option used to
> delegate IPv6 address space to simple IPv6 sites.  The PD option,
> which lists the global prefixes that a site may use to number its
> network, is attached to IPv6 Neighbor Discovery Router Advertisement
> messages that are sent across a point-to-point link from a provider's
> router to a site's border router.  This document defines the
> mechanism by which a site router processes the PD option and
> configures each of its attached links allowing hosts within the site
> to obtain global addresses using address autoconfiguration.

A few comments.

2. Terminology

==> is necessary to define basic stuff like 'node' and router here.  A 
reference to RFC2460 or whatever should be sufficient?

3.3. Site router operation

   Upon receiving a Router Solicitation message containing a Prefix
   Delegation option, the router MUST process the message as described
   in [DISCOVERY] and [ADDRCONF] before processing the PD option.

==> Router Advertisement, not Solication?  PD should only be used in RA.

4. Prefix Delegation option format

	Prefix Length  8-bit unsigned integer.  The number of leading bits
	               in the Prefix that are valid.  The value ranges   
	               from 0 to 64.

==> The format supports anything from 0 to 128, when though some of those 
make no sense.

5. Security considerations

   Security issues regarding the Neighbor Discovery protocol are
   discussed in [DISCOVERY].

==> doesn't PD bring up any new issues?  Bring more weight to existing
ones?  I bet it does :-).  For example, if the point-to-point link is an
IPv6/IPv4 tunnel, it might be possible to inject RA packets with bogus PD
options..

General comments: this would affect how routers (that is, CPE) work wrt. 
NDISC: basically the point-to-point link towards the ISP would have to 
operate in "host" mode so it could sent RS's and be able to receive RA's.  
I think changes to the current specification need to spelled out in a 
separate chapter.

One might also consider whether CPE should immediately send out RA's with 
a new prefix (and advertise the old one with lifetime of zero or whatever) 
when the prefix delegated from upstream changes.

I'd move acknowledgements from introduction to a separate chapter, as is 
usual.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
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: Francois Menard <[email-masked]>
Date: Mon, 25 Feb 2002 08:03:13 -0500 (Eastern Standard Time)

Is there a document which describes in details IPv6 multi-homing (in the
context of public NAPs).

Does one ISP need to get a /35 at a minimum in order to be globally
routable on the public IPv6 Internet?

f.

--
Francois D. Menard
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Feb 2002 00:56:06 +0200 (EET)

> routable on the public IPv6 Internet?

This is a routing policy issue, not a subject for ipng I think.  
[email-masked] would be one list, multi6 another.  There is a '6bone 
routing guidelines' RFC.

(currently about /35 is required.)