Subject: Reminder: IPv6 WG Last Call:draft-ietf-ipv6-rfc2462bis-02.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 12 Jul 2004 21:36:59 +0900

Reminder: the following wg last call will end tomorrow (July 13th).
So far, I've only seen one comment in response to the last call (the
one from itojun about "disabling interface" on DAD failure).

I'm afraid wg members are too busy for processing a rush of new I-Ds
or for writing/updating their own drafts, but if anyone of you could
review the document by the end of the last call, it would really be
appreciated.

Right now, I'm planning to revise the draft once again before the
final I-D cutoff on July 19th.

Thanks,

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

>>>>> On Tue, 29 Jun 2004 06:31:13 -0400, 
>>>>> Brian Haberman <[email-masked]> said:

> All,
>       This note starts a 2 week IPv6 Working Group Last Call on:

> 	Title		: IPv6 Stateless Address Autoconfiguration
> 	Author(s)	: S. Thomson, et al.
> 	Filename	: draft-ietf-ipv6-rfc2462bis-02.txt
> 	Pages		: 30
> 	Date		: 2004-6-17

> being recycled at Draft Standard.  All substantive comments should be
> directed to the mailing list.  Editorial comments can be directed to
> the mailing list or the editor.

> This last call will end on July 13, 2004.

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

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 12 Jul 2004 16:20:21 +0300

In reviewing this document one question comes to mind from my own personal
experience with IPv4 network and it is related to "zero touch provisioning".
I realize that this is for stateless provisioning, but I still could not see
where this would fall other than here.

Background:
Under the standard "zero touch provisioning" situation the network
management system (NMS) assigns an IP address to the Provider Edge (PE)
router port. When the Customer Edge (CE) router is connected for the first
time and then powered up it "sees" the IP address of the other end of the
link and assigns itself the next higher one. So it looks like:

(Provider Edge router) AAAA::0001 ---- (Customer Edge router) AAAA::0002

Once this IP address is assigned and registering on the network the specific
configuration required based on the services purchased are uploaded into the
router and the new configuration and security are applied.

Question:
Given that this does not include a DHCP server (either v4 or v6) but
requires explicit IP assignment from the NMS, how would this work given this
draft?

Eric

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 15 Jul 2004 01:20:44 +0900

>>>>> On Mon, 12 Jul 2004 16:20:21 +0300, 
>>>>> "EricLKlein" <[email-masked]> said:

> requires explicit IP assignment from the NMS, how would this work given this

I'm not sure if this question even has any relationship with
rfc2462bis...if it is enough for the CE to know (one of) the PE's
address in order to assign a similar address (perhaps an address with
the same prefix and a slightly different interface ID) using its own
API (like the "ifconfig" command of UNIX-like systems), then the CE
can (theoretically) use:

- inverse neighbor discovery (RFC3122), or
- ICMPv6 name lookups (draft-ietf-ipngwg-icmp-name-lookups-10.txt)

					JINMEI, Tatuya

p.s. right now, I don't think this issue (if we need to call it an
issue) is a show-stopper to advance rfc2462bis.

---

From: "EricLKlein" <[email-masked]>
Date: Wed, 14 Jul 2004 20:24:07 +0300

> issue) is a show-stopper to advance rfc2462bis.

I agree, it was more of a next step question. The document looks good to go
from my point of view.

Eric