On 12/11/2012 17:33, Mark Townsley wrote: > 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.
Which is a FAIL if there are any v6-only devices around. Ultimately I don't see how you can avoid some kind of warning to the user, even if it's the equivalent of the beeping from a smoke detector whose battery is fading. Brian > - 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
