Oops, meant to reply to the list the first time... I see no reason not to do this... we'd have to have just about as much information to bridge successfully, and a few hundred routes is no big deal.
Andrew On 8/11/2012, at 3:49 PM, Acee Lindem <acee.lin...@ericsson.com> wrote: > 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 <brian.e.carpen...@gmail.com> >> 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 >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> _______________________________________________ >> 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
