Independent of the routing protocol, I don't think we want to inject a /128 advertisement for every device in the homenet into the homenet routing domain. Acee On Nov 8, 2012, at 3:21 PM, Andrew McGregor wrote:
> This whole thread is making me think that specifying that we use either babel > (with attention to getting it documented properly) or one of the OSPFv4 MANET > extensions, in the case where we have only a /64 and perhaps any time we find > we have an 802.11s, ad-hoc or NBMA interface in play. That way we introduce > /128 routes, and everything continues to work. > > Andrew > > On 8/11/2012, at 10:51 AM, Brian E Carpenter <[email protected]> > wrote: > >> On 08/11/2012 15:09, Victor Kuarsingh wrote: >>>>> even though this would destroy the benefits of subnetting. >>>> <RCC>I think it is arguable whether bridging is the least damaging >>>> solution. It fundamentally does not work with route-over multi-link >>>> subnets and would therefore require some extra L2 weirdness at a LLN >>>> border router. If ISPs are going to hobble us with /64s then I think you >>>> will find NPTv6 solutions appearing for the same reason NAT is used >>>> today. There are alternatives but, as noted in the architecture draft, >>>> these break SLAAC. So I think the onus is to push back on ISPs ofering >>>> /64s if we want to avoid any kludges.</RCC> >>> >>> Just to further some of the comments I made yesterday. I understand the >>> we don¹t want a /64 to show up, but this may occur for reasons other then >>> the primary intention of the ISP. Many things occur in a network - IP >>> depletion/low avail blocks, errors, mis-configuration etc. No matter why >>> it occurs, ignoring this case is likely not a good idea. >>> >>> I agree with earlier comments that this can be considered as a failure >>> mode. It still needs to be considered for good engineering on how CPEs >>> and homenet gear will behave. >> >> Exactly. It would be very bad for the end users to ignore this reality. >> >> On 08/11/2012 15:02, Sander Steffann wrote: >> >>>>> So let's just say that giving a single /64 to the home is incompatible >>>>> with homenet architecture, and we need more addresses. I'm fine with that. >>> >>> Yes please. I think some ISPs *need* to get a signal like this. >> >> Sure, but that does *not* excuse us from specifying how the end user >> gets service in such a situation. >> >> Brian >> >> _______________________________________________ >> homenet mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
