Nice to see a constructive thread with suggested text for the editors of the homenet arch, thank you.
I'm concerned with any "issue a warning" type suggestions though. We are working hard to develop automatic configuration that assumes there is no operator involved here. If there is no operator to configure our protocols, there is no operator to issue a warning to either. If the homenet runs out of /64s to hand out, and we recommend not to route /128s, bridge, NPTv6, etc... then the final option is, simply, "no IPv6" for that given link. Falling back to the user to try and interpret a cryptic message about IPv6 prefixes is simply not a realistic option for the protocols we are working on here. - Mark On Nov 12, 2012, at 3:05 PM, Mattia Rossi wrote: > >> If I'm the downstream router, I can't get a prefix, of course I issue >> warning message. However, if I'm the one who still get an /64 and works fine >> as a leaf, I won't issue an warning message for a fore-coming downstream >> router attached to me. >> > So you have to implement a check and some sort of warning mechanism for not > getting a PD anyways in all your devices (as I suspect that all of them could > eventually be used as a "downstream" router). I don't think that it's much > more difficult to check whether the PD was for a /64. You have to do that > anyway, as your DHCP server won't be able to create a PD from a /64 and issue > a warning in any case. So actually no real extra work needed there. > > <non technical reason start> > The problem with having just the downstream router warning you though, is > that in the case of multihoming, and two prefixes being provided to the > homenet, one /64 from ISP1 and one /56 from ISP2, the downstream router might > get them over the same interface, and simply issue no warning, as it's happy > with the /56 from ISP2, and route everything over that ISP, without the user > ever knowing. If the upstream router issues a warning about getting a /64 > over an interface from an ISP, the user knows there's something wrong and can > fix things, and avoid unnecessary high bills. > </non technical reason end/> > > After the input of various posts I'd like to change the text in 3.4.1: > > The home network needs to be adaptable to such ISP policies, and thus > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if > only a /64 is offered by the ISP, the homenet may be severely > constrained (with IPv6 not reaching all devices in the home, or use > of some form of IPv6 NAT being forced), or even unable to function. > While it may be possible to operate a DHCPv6-only network with > prefixes longer than /64, doing so would break SLAAC, and is thus not > recommended. > > to the following text: > > The home network needs to be adaptable to such ISP policies, and thus > make no assumptions about the stability of the prefix received from > an ISP, or the length of the prefix that may be offered. However, if > only a /64 is offered by the ISP, the homenet may be severely > constrained. Attempting to use subnet prefixes longer than /64 > would break SLAAC, and is thus not recommended. Using ULA prefixes > internally with NPTv6 at the boundary would be possible, but is not > recommended for reasons given elsewhere. Reverting to bridging would > destroy subnetting, breaks multicast if bridged onto 802.11 wireless > networks and has serious limitations with regard to heterogeneous > link layer technologies and LLNs. For those reasons it is recommended > that DHCP-PD or OSPFv3 capable routers have the ability to issue a warning > upon receipt of a /64 if required to assign further prefixes within > the home network as described in Section 3.4.3. > > > Mat > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
