On Sat, 31 Jul 2010 10:06:11 -0400 Christopher Morrow <christopher.mor...@gmail.com> wrote:
> On Fri, Jul 30, 2010 at 10:17 PM, Mark Smith > <i...@69706e6720323030352d30312d31340a.nosense.org> wrote: > > On Wed, 28 Jul 2010 18:49:18 -0400 > > Christopher Morrow <christopher.mor...@gmail.com> wrote: > > > >> (most of the discussion seems to be revolving around a simple, to me, > >> phrasing problem, but) > >> > >> On Wed, Jul 28, 2010 at 5:53 AM, Hemant Singh (shemant) > >> <shem...@cisco.com> wrote: > >> > >> > We are discussing off-link model and RFC 5942 is described in this RFC. > >> > Further, when an interface of a router acquires an IPv6 address or > >> > receives an RA, the interface is acting as a host. > >> > > >> > >> anyone that configures a router with RA is headed for disaster > >> anyway... (not a cpe device mind you, though most of those will get > >> addressing via pppoe/pd and not RA so...) > >> > > > > I wouldn't be so sure about that - the CPE draft says the following > > about WAN interface configuration, with Router Discovery i.e. RAs is a > > MUST - > > I did say 'not a cpe device'... I was replying to the your comment in brackets about CPE provisioning. I should have been clearer. > I would point out that a /64 with your > customer on it is a very large place to hide :) (nd probing/scraping > probably finds the customer easily, but strikes me as heavyweight to > find a customer you know is at the end of a ptp dlci/vc) > > > W-1: When the router is attached to the WAN interface link it MUST > > act as an IPv6 host for the purposes of stateless or stateful > > interface address assignment ([RFC4862] / [RFC3315]). > > > > W-2: The IPv6 CE router MUST generate a link-local address and > > finish Duplicate Address Detection according to [RFC4862] prior > > to sending any Router Solicitations on the interface. The > > source address used in the subsequent Router Solicitation MUST > > be the link-local address on the WAN interface. > > > > W-3: Absent of other routing information the IPv6 CE router MUST use > > Router Discovery as specified in [RFC4861] to discover a > > default router(s) and install default route(s) in its routing > > table with the discovered router's address as the next-hop. > > > > W-4: The router MUST act as a requesting router for the purposes of > > DHCPv6 prefix delegation ([RFC3633]). > > > > W-5: DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation > > (IA_PD) SHOULD be done as a single DHCPv6 session. > > > > these seem good though, in principle. I wonder how (probably not for > this list/discussion though) this works out in practice. > I think it can be on topic if scalability on protocols dictates updates to RFCs. For example (although it may already be legal), a slight update to allow unsolicited RAs to have unicast layer 3 destinations may be necessary to help scale RA operation on customer aggregation routers carrying 1000s of subscribers. The other way to mitigate or remedy it would be to wind up the values of RA periodic timers. In a broadband PPPoE environment, an RA once an hour to each subscriber would probably be enough. > I still hold to the 'anyone who uses RA for router (real router, not > cpe) interface address assignment is headed for disaster' there's no > way to manage/monitor/maintain/etc in a non-deterministic config such > as that. operations folks heads will explode :( > I agree. In my experience, the CPE space is the more interesting / challenging at the moment. Regards, Mark. > Thanks! > -Chris > > > > > > >> I think the case that maz/miyao outlined is a normal internet backbone > >> router, it has many interfaces (several hundred), it has many (several > >> hundred) bgp sessions to neighbors. today the interfaces are being > >> configured as /127's in some cases. > >> > >> This draft, which I support as being a working group item (we really > >> should just discuss that portion first, then argue language issues), > >> only seeks to clarify that using /127's (or for thayler: "two > >> addresses on a single link, which may coincidentally be adjacent > >> addresses") is common operations practice and should be supported by > >> routing equipment vendors. > >> > >> -chris > >> (can we call the question in a clean/new email about adoption pls? > >> There was interest in the room for same.) > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
