Re: [homenet] homenet naming drafts "terminology"
Is this the same as a hidden primary name server? Cheers Ole > On 5 May 2021, at 21:09, Michael Richardson wrote: > > > Ted Lemon wrote: >>> On May 5, 2021, at 11:51 AM, Michael Richardson >>> wrote: >>> 3) We would be happy to go with another term, but we don't want to >>> invent another term. So, if the DNS anycast operator has another >>> term, then I'd go with it. > >> Authority database? > > I thought that you were asking who was an authoritive database of operators. > Then I understood that you are suggesting "authority database" as the term. > > Some ascii art, (so pick a sensible mono-spaced font, or use the archive > link): > > .-. .-. > | S P | ---> | D M |\---\--\ > `-' `-'| | | >V V V > .-. .. .. > | Sec | | Sec| |Sec | > `-' `' `' > > S.P. = Stealth Primary > Sec = Secondary > D M = Distribution M* > > Note that the "DM" is usually not listed as an NS, but rather, > two or more "Sec" are what is listed. > > So, maybe "Distribution Authority" would make us both happy. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > ___ > 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
Re: [homenet] Support for RFC 7084 on shipping devices...
Hi Ted, >> Are you saying there might be gaps in HNCP? Or things we could do to make it >> more deployable? >> If it's just a matter of running code missing, I'm not sure defining >> anything else new in the IETF would help that problem. > > There are definitely missing features from the protocol that I’d like to add. > But I think the fact that the protocol isn’t deployed on a _single_ > commercially available router, and is not really usable on OpenWRT by a > non-expert, is an indication that there is substantial remaining work to do. > Operations work is not out of scope for IETF; maybe I should have asked this > on v6ops. We have historically said “not our problem,” but I don’t agree > that that’s the right answer. If HNCP had really convincingly solved the > problem, we would not be seeing what we are seeing. I believe HNCP has solved the technical problem it set out to do. Allow for an automatically configured, arbitrary topology network with multiple exits. The deployment challenge of that is that every router must support HNCP and must support SADR. >> I know why I haven't implemented HNCP on software I work on... and I also >> know that there aren't any very realistic alternatives either. > > Can you say why that is? Quite a few reasons, some which might be not relevant to your case of course. - the pendulum between distributed algorithms and centralized controllers is for the problems I'm working on largely towards the centralized side - it's quite a lot of work. it requires a new routing protocol, it requires a changed forwarding paradigm, and it requires integration with a lot of features - it does not support the case "permissionless extensions of the network". >> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing >> and routers. I.e. what happens at the network layer. > > You mean at the “internet layer,” I assume? No, I mean the network layer. RA guard operates as a layer violating feature at the data-link layer. >> If you are talking about what happens at the often integrated bridge CE >> devices have, then sure, they could implement RA Guard. >> But having your additional router sending RAs across the homenet might not >> be a particularly good idea anyway. > > Why not? What would be a better idea? I don’t mean to say that using RAs > in this way is ideal, but what’s the alternative that doesn’t involve the > vast complexity of per-host routing? I don't understand how it would work. Add another router with it's own link. How would you get addresses for that link? Make them up from ULA? And then advertise that in an RA upstream with the MSR option? That would put a lot of responsibility on the hosts of getting things "right". And what if you added two of your routers, or connected them differently? Per-host routing is in itself trivial and likely scales orders of magnitude further than you need. But there are problems with MLSR that are unsolved / not solved to my liking yet there. >> Sounds like you need to set it up as a NAT. > > I really hope you are just making a funny joke here. But it’s not very > funny. What I want is something that’s operationally simple, not something > with lots of moving parts that have to be kept track of. NATs in particular > suck for any UDP-based protocol. for "permissionless extensions of the network" there isn't much else than NAT. Your other likely option is an ND proxy. If you are very sure that nothing else can be added to the network (we don't want to build a spanning tree protocol out of ND). >> I wasn't thinking of doing it exactly like the 6lowpan does it. >> Regardless I don't see why scaling should be problematic, are you planning >> to have millions of rapidly moving hosts on your shared /64 network? > > If you have N devices on a single link on the other side of the router, then > when using either RA or a routing protocol, the amount of information you > need to propagate to get things working is very small: just a prefix and a > router. If you can’t do that, then the amount of information you need to > propagate is at a minimum N units, and possibly K*N, for some not > insignificant factor K. > > To be clear, the reason I’m concerned about this is that I’ve looked at > implementing it on OpenWRT, and it’s at least roughly doubling the complexity > of the work required, even if you can depend on using IPv6. If you have to > use IPv4 on one side, then it’s even more complexity. And it’s utterly > stupid complexity—it adds no value over subnetting. Why add that to the > network? Because you don't like the mechanisms for automated subnet assignment? ;-) And no, I'm not suggesting we should do MLSRv2 as a competitor for HNCP. MLSRv2 would also require an update to every router, and a network operator allowing extensions to the network. > This is why I’m asking people if they have knowledge of what is actually > deployed. I think
Re: [homenet] Support for RFC 7084 on shipping devices...
Homenet has solved the problem of self-configuring networks in arbitrary topologies. >>> >>> If that were true, I wouldn’t be asking this question. We’re still >>> chugging along, but we don’t have something that nay router vender could >>> even consider shipping right now. There isn’t enough participation in >>> homenet anymore for us to really iron out the kinks. Certainly if I could >>> count o homenet being present in routers in the home, we wouldn’t be having >>> this conversation! :) >> >> Since this was sent to an IETF list I assumed you were focused on standards. >> (And presumably also running code). :-) > > It’s the running code that’s the problem. What I’m hunting around for is > whether there are some things we need to do that we haven’t yet done. I > wish I could say “just turn on Homenet and everything will be fine,” but we > aren’t in a position to say that yet. If people are feeling satisfied that > homenet is “done,” we (the IETF, and the Internet community in general) have > a problem. > > We’d been tempted to punt on this because there are perfectly good commercial > solutions that solve this problem with L2 bridging, but those don’t work when > you need to route between WiFi and e.g. 6lowpan networks. Are you saying there might be gaps in HNCP? Or things we could do to make it more deployable? If it's just a matter of running code missing, I'm not sure defining anything else new in the IETF would help that problem. I know why I haven't implemented HNCP on software I work on... and I also know that there aren't any very realistic alternatives either. - single router and bridging (7084) >>> >>> If it doesn’t filter RA, and I control the second router, I’m okay, right? >> >> Well, yes it isn't a router at that point, it's a bridge. > > The reason I mentioned this particular problem is that I’ve heard reports of > 7084 routers implementing RA guard, which sort of makes sense, but it totally > breaks this use case. RA guard isn't applicable in a RFC7084 context. RFC7078 talks about routing and routers. I.e. what happens at the network layer. If you are talking about what happens at the often integrated bridge CE devices have, then sure, they could implement RA Guard. But having your additional router sending RAs across the homenet might not be a particularly good idea anyway. Sounds like you need to set it up as a NAT. - arbitrary topology plug and play (homenet) >>> >>> Yes, that’s homenet. It would really help if folks who think homenet is >>> done would try to deploy it in their home using OpenWRT and see how it >>> goes. Seriously. This is not a solved problem. We’re maybe 50-60% of >>> the way there at this point. I’ve been trying to make progress on this >>> ever since HNCP was declared done, and occasionally get collaboration, and >>> indeed we may be begining to make progress agan, but we could definitely >>> use more participation if there are folks in 6man who want this to work and >>> imagine that it already does. >> >> The notion of "permissionless extensions of the network" is still somewhat >> unresolved. HNCP allows for that, but as we know it's not well >> supported/deployed. I had some hopes for multi-link subnet routing >> (implemented how it was originally intended, not as spanning tree in ND). >> But I have never gotten around to flesh that out in detail. Pascal has done >> various stuff in this space for lowpan, which may be something to build on. >> >> The MLSR idea is basically a /64 shared across all links. Hosts register >> with routers using ARO (or DHCP). Routers advertise host routes in a routing >> protocol between themselves. The tricky parts are of course detecting when >> hosts go away, detecting movement and so on. > > I’ve seen this. It’s how the 6lowpan folks seem to have defined their > “routing." But scalability is horrible, and when I’ve looked at doing an > implementation, it’s obviously ridiculously harder than just publishing an > RA. And it’s particularly hard if there’s no IPv6 on North Network.So > if there’s a way to get IPv6 to work in this case, that seems like a better > option. I wasn't thinking of doing it exactly like the 6lowpan does it. Regardless I don't see why scaling should be problematic, are you planning to have millions of rapidly moving hosts on your shared /64 network? >> A side meeting in Singapore perhaps? > > I’m not going to be in Singapore—I just can’t justify the carbon footprint. > I do think we ought to have a deeper discussion about this, though. Maybe a > “virtual interim”? If there’s interest, I’d be happy to organize this. > I’d also be happy to attend a side meeting in Singapore remotely, but our > experience with that thus far has been pessimal, and I don’t think a fix is > planned for Singapore (unless I just haven’t heard about it). Cheers, Ole ___
Re: [homenet] Support for RFC 7084 on shipping devices...
Ted, >> Homenet has solved the problem of self-configuring networks in arbitrary >> topologies. > > If that were true, I wouldn’t be asking this question. We’re still chugging > along, but we don’t have something that nay router vender could even consider > shipping right now. There isn’t enough participation in homenet anymore for > us to really iron out the kinks. Certainly if I could count o homenet being > present in routers in the home, we wouldn’t be having this conversation! :) Since this was sent to an IETF list I assumed you were focused on standards. (And presumably also running code). :-) >> Unless someone goes to lengths describing exactly how this is supposed to >> work, the idea of "simplifying" the homenet solution sounds like a recipe >> for failure. > > I tend to agree, but wasn’t proposing that. I was really just trying to > solve the very specific problem of how I do IPv6 routing in the case I > described, given the hardware that is likely to be present in the home. > >> How are you going to tell the customers that you can only plug in devices in >> particular topologies and in particular ways. > > The customer already has a router. Suppose I want to add a router with a > bunch of devices behind it, and I know the router I’m adding will never have > a second layer behind it. Can I get it to work? That’s the problem. > >> - single router and bridging (7084) > > If it doesn’t filter RA, and I control the second router, I’m okay, right? Well, yes it isn't a router at that point, it's a bridge. > >> - arbitrary topology plug and play (homenet) > > Yes, that’s homenet. It would really help if folks who think homenet is > done would try to deploy it in their home using OpenWRT and see how it goes. > Seriously. This is not a solved problem. We’re maybe 50-60% of the way > there at this point. I’ve been trying to make progress on this ever since > HNCP was declared done, and occasionally get collaboration, and indeed we may > be begining to make progress agan, but we could definitely use more > participation if there are folks in 6man who want this to work and imagine > that it already does. The notion of "permissionless extensions of the network" is still somewhat unresolved. HNCP allows for that, but as we know it's not well supported/deployed. I had some hopes for multi-link subnet routing (implemented how it was originally intended, not as spanning tree in ND). But I have never gotten around to flesh that out in detail. Pascal has done various stuff in this space for lowpan, which may be something to build on. The MLSR idea is basically a /64 shared across all links. Hosts register with routers using ARO (or DHCP). Routers advertise host routes in a routing protocol between themselves. The tricky parts are of course detecting when hosts go away, detecting movement and so on. A side meeting in Singapore perhaps? >> - manually configured (meaning ansible, scripts or whatever automation >> solution external to the routers themselves). > > Yech. That’s not an option. :] Cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Support for RFC 7084 on shipping devices...
Mikael, >> RFC7084 does not have any support for internal routers. > > While this is true, OpenWrt does support DHCPv6-PD within the home, out of > the box. I also have a report of AVN Fritzbox supporting sub-PD without > additional configuration. > > In all devices I've looked at the WAN is WAN, it comes up with firewalls on, > requests PD etc, and if it doesn't get it then there is no GUA IPv6 on LAN. > > In my opinion the work in homenet could be leveraged into an operational > document where recommendations on what parts of homenet could be easily > implemented to make it work within a home (without implementing everything), > thinking primarily of "firewall off" and "service discovery proxy on". If no > PD was available, turn ethertype 0x86dd bridging on between LAN and WAN. I > guess we would still need to do NAT44 because without HNCP there wouldn't be > a route to the IPv4 network on LAN of the "sub-router". > > It would however mean that a printer on the sub-router LAN could be reached > over IPv6. In order for this to happen without HNCP then this sub-router > would need to send RAs on its WAN announcing reachability to its LAN IPv6 > prefix (either GUA+ULA if PD is available, otherwise just ULA). I have never > seen RA guard or similar functions in residential equipment, so I would > expect this to work. There has been multiple proposals in that direction. None of them succeeded, because they left too many corner cases "undefined". Homenet has solved the problem of self-configuring networks in arbitrary topologies. Unless someone goes to lengths describing exactly how this is supposed to work, the idea of "simplifying" the homenet solution sounds like a recipe for failure. How are you going to tell the customers that you can only plug in devices in particular topologies and in particular ways. - single router and bridging (7084) - arbitrary topology plug and play (homenet) - manually configured (meaning ansible, scripts or whatever automation solution external to the routers themselves). Cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Support for RFC 7084 on shipping devices...
Ted, [top posting] RFC7084 does not have any support for internal routers. Futher: It might just be the way you describe the use cases, there seems to be a misconception about how routers work with regards to ND “advertisements”. ND is not a routing protocol. Hierarchical PD which you also allude to, was proposed, has limitations and was not standardized. That why HNCP was done. If you have a set of rfc7084 routers I believe you are left with manual configuration of prefixes and either manually configured static routing or RIP. Cheers Ole > On 4 Oct 2019, at 02:40, Ted Lemon wrote: > > (If you got this as a Bcc, it’s because I am hoping you can contribute to > the discussion, but might not be on the mailing list to which I sent the > question, so please answer on-list if you are willing.) > > I’ve been involved in some discussions recently where the question has come > up: how good is support for RFC7084 in shipping routers? And what gaps > exist in RFC7084 that could cause problems? And in cases where RFC7084 > support either isn’t present, or isn’t useful because no IPv6 or because ISP > is delegating a /64, what things might work and what things might not, if we > want bidirectional reachability between two separate network links in the > home. > > So for example, suppose we have "CE Router," which supports RFC7084, > including prefix delegation. And we have "Internal Router" on that network > requests a delegation, and gets a prefix from the CE router. Presumably that > prefix is out of a larger prefix that CE Router got from the ISP. Great so > far. Let’s call the network on the southbound interface of Internal Router > “South Network”. Let’s call the network on its northbound interface, which is > also the network on CE router’s southbound interface, “North Network.” > > viz: > >ISP > | > CE Router > | > North Network > |---+--+-| > | | > Internal Router + Node A > | > South Network > |---+---+| > | > Node B ---+ > > > If I want hosts on South Network to communicate with hosts on North Network, > what do I have to do? Should Internal Router publish an RA on its > northbound interface? What is the likelihood of that being filtered by the > network? If packets for South Network are forwarded through CE Router, will > it forward them on to Internal Router, forward them north, or drop them? > > Similarly, suppose we have a network where unfortunately PD Isn’t available > internally, but IPv6 is present on the northbound interface of the internal > node and southbound interface of the CE router. Suppose further that > Internal Router allocates itself a ULA prefix and advertises that as > reachable and on-link on its southbound interface, and as reachable but not > on-link on its northbound interface. Will that be blocked at layer 2 by CE > Router? I’m sort of assuming here that the CE router is managing the North > Network link, which is probably WiFi. > > Okay, now what if there’s no IPv6 support on CE Router or being provided by > CE router on North Network. Suppose Internal Router allocates a ULA and > allocates two /64s out of the ULA, one of which is advertised as reachable on > its northbound interface and on-link on its southbound interface, and a > second of which is advertised as on-link on its northbound interface and > reachable on its southbound interface. > > Fourth possibility: Node A is manually configured with an IPv6 address on a > prefix that Internal router is advertising as reachable on its southbound > interface, but which is not advertised on South Network because of filtering. > Node B has an address on a prefix that Internal Router is advertising as > on-link on its southbound interface. Node A has a static route configured > through Internal Router to the second prefix. Is there any reason to think > that traffic between Node A and Node B will be filtered at layer 2 by CE > Router, assuming that traffic on North Network is all going through CE Router? > > The goal here is to have bidirectional reachability between the two nodes on > IPv6 using either a global prefix or a ULA. The concern is that something > could prevent each of these cases from working. What I’m really curious > about is whether people have experience with doing communications of this > type using actual routers that ISPs are shipping. Is this “internal > network” scenario part of acceptance testing for
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
A host SHOULD select a default gateway for each prefix it uses to obtain one of its own addresses. That router SHOULD be one of the routers advertising the prefix in its RA. As a result of doing so, when a host emits a datagram using a source address in one of those prefixes and has no history directing it otherwise, it SHOULD send it to the indicated default gateway. The question is to which one (if there are multiple): this might be important for e.g. fail-over cases or if you want to dynamically optimize away that extra hop you mention. yes, that text should be changed to accommodate multiple default routers. ref rfc4311. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. the rule we are proposing is something like: “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” the subnet model in IPv6 assumed that all routers on a link had equal reachability. this rules solves the case where there are two routers with different reachability (and addressing) on a single link. currently hosts that don’t do implement this, typically suffer from long time outs and broken connectivity. with the above rule I don’t see how offlink/onlink or DHCPv6 makes any difference. if there isn’t a PIO, well then the host is left uninformed. can you construct an example where the rule breaks things and that not having the rule wouldn’t? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. the rule we are proposing is something like: “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” Check. And PIO here can be RIO as well? no, I don’t think it can. the RIO says nothing about the link itself. What about if there are several PIO/RIOs of different size, do we do longest matching on them to prefer one? Or shortest because the guy with the shortest prefix (not /0) is more likely to be the one closest to the uplink? two PIO’s of different length on the link sounds like a configuration error. can you construct an example where the rule breaks things and that not having the rule wouldn’t? No, I am still trying to figure out exactly what is being proposed. Next step is to try to come up with something that'll make things break. good. ;-) cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix. I take it IA_PD was included above by mistake. No. an IA_PD prefix is by definition not assigned to the link between RR and DR. This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix. true. but I’m not sure what bearing that has with the host rule in question. I’m also wondering if you are making a wrong assumption of what an L=0 PIO entails. I don't know. Am I? I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case. are you talking about something different than 3633 DHCPv6 prefix delegation? if the SA doesn’t match a PIO on link, then the next-hop on that interface is chosen like it is today. if you’re inventing new stuff like host IA_PD derived addresses, then that’s something someone has to specify. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Juliusz, “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” It took me a while to decode that. If anyone else is as stupid as I am, here's the translation When selecting the (source, destination, next-hop) triple among available routes for a given destination prefix, prefer one whose next-hop is a router that sent an RA with a prefix that covers the source address under consideration. thanks for the readable version! ;-) now, can you please write one for hosts that only have a Default Router List (as in no routing table). (I don’t object if we only describe the conceptual host model for type C (4191) hosts though. Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals? I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6. I’ll try. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, in the land of contrived examples! :-) this working groups answer to the below is make this a homenet and run HNCP. then the host rule enhancement isn’t used. in any case let me try to reply below, although I’m quite confused about the example. two PIO’s of different length on the link sounds like a configuration error. Then I must still be missing something. Example time: A B+-+F + + | | ++-++ | | + + C D + | + E A, B and D are routers. A has received a /56 from ISPA. D has been delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also advertising ISPA /56 as off-link to indicate that it'll handle the entire /56. currently, advertising a PIO with L=0 isn’t a routing advertisement (“handle the prefix”?). it only affects a hosts prefix list and how it does onlink determination for addresses in that prefix. i.e. a host would first chose D and NH, then find a suitable source. with the new rule, the PIO becomes more like a source constrained route. “for any source address matching prefix in PIO, send traffic to me”. I don’t understand what you would gain from the ISPA/56 PIO over the ISPA/64 you’d have in C already. Now, C takes itself a couple of addresses from the ABCD /64 (because A=1) and does DHCPv6 IA_NA. A then hands it an address from outside the /64 (because that was configured for some reason). A has a /120 route pointing to its interface that ABCD sits on, so that this DHCPv6 IA_NA works (because it's outside the on-link /64). D is a RFC7084 router and has requested IA_PD from A and received another /64, which it then uses to put on the DE link. Now, do we want D to do anything to tell C that E is reachable through D? Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and let all traffic from C to D bounce via A? Do we want A to in some way announce the delegated /64 IA_PD prefix? 1) run homenet / routing protocol 2) absolutely not 3) RIO with router lifetime of 0 could work but geez this is what homenet solves 4) yes 5) no What do we want A to do, should it announce the /120 as off-link? On-link might make sense in this case. that would only affect hosts on the ABCD link. D would still send all traffic for the /120 to A (as default route) B has F behind it, I guess we want this to get an address as well, from ISPA prefix. Do we want B to send out an RIO for this /64? you want B to run homenet. So for C, the world view might now look like this: /56 RIO or PIO (depending on what we want to do) for ISPA prefix I don’t see that you need either. /64 on-link PIO from A for the on-link ABCD /64 prefix yes. /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix possibly. probably not needed. /64 RIO (?) from D for its DE /64 /64 RIO (?) from B for its BF /64 Or do we want above RIOs to be off-link PIOs instead? they would be RIOs. since you want destination routes, and not source routes. in (D,S) SADR notation. a RIO: (DE/64, *) while PIO: (::/0, DE/64) please use homenet protocols. don’t build networks like this! cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals? I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6. Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't have to be covered by an on-link prefix. You don't get any SLAAC based addresses without an on-link RA for the prefix with A=1. So this is obvious that there needs to be an RA sent. RA’s are sent regardless of DHCP or SLAAC. you can do SLAAC with A=1, L=0. For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix. I take it IA_PD was included above by mistake. This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix. true. but I’m not sure what bearing that has with the host rule in question. I’m also wondering if you are making a wrong assumption of what an L=0 PIO entails. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] question: equal-cost multipath?
I am interested to learn what people think about whether equal-cost multi-path routes are needed in homenet. Given the previous discussion about parallel wireless links - which I know I have in my house and can't use - I've been wondering if these have been considered. ECMP is critical in the data-center and backbone, but I'm interested in seeing what the reasoning is as to why it isn't or is needed in the homenet scenarios. I don’t think homenet has any special requirements with regards to ECMP. I think it has been assumed that will work like in any other network. I certainly expect the homenet to support ECMP. (parallel wireless links may be a bad example though, as they are probably quite unlikely to be equal.) the main items of discussion in a homenet context is load balancing across multiple providers. in the IPv6 multi-prefix multi-homing architecture load balancing is done by the hosts, not by the network. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Fred, Add another LAN interface to Alice, connecting host Porky. If Alice didn’t advertise both ISP-Alice and ISP-Bob prefixes, Porky couldn’t use ISP Bob. It would be a quite complicated set of rules determining when Alice should or should not include ISP Bob’s prefixes on a given link. I’m quite uncomfortable tying Router Advertisement PIO’s to routing and topology changes. I think Brian makes a good point on slide 9: https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf +---++———+ | || | |ISP-Alice ||ISP-Bob | | || | | || | +--+++-++ | | +--+--+ +-+-+ |Alice| |Bob| +--+--+ +-+-+ | | ++-+--+++ || +--+---+ +--+—+ |Spanky| |Carol| +--+ +--+———+ | +++——+ | +--+——+ |Alfalfa| +———+ cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] IntDir review: draft-ietf-homenet-dhcp-07
I have been selected as the Internet Directorate reviewer for this draft. The purpose of the review is to provide assistance to the Internet ADs. Although these comments are primarily for the use of the Internet ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-homenet-dncp-07.txt Reviewer: Ole Troan Review Date: July 7 16, 2015 The document now reads much better. I do get the impression that the text is reverse engineered from code in a few places though. Given that it is an Abstract protocol specification, that must be combined with a profile specification to be a fully implementable, it is somewhat difficult to predict if the specification is complete or not. Juliusz Chroboczek is writing an independent implementation, and I'd recommend incorporating the very informative replies the authors have made to his comments on the homenet list into the document. General comments: = = Replace no affiliation with Independent. If that's the case. = It is unclear to me how multiple instances of DNCP is run on a link. Is that something that must be specified in the profile document, and each profile must support multiple instances? Given draft-stenberg-shsp, and the way it hijacks the HNCP profile, it appears that more formal multiple instance support would be needed. = I can't help being left with the impression that fragmentation (section 6.3) is underspecified. Can fragmentation be left out of the protocol for now (and profiles requiring large TLVs can require a transport layer supporting segmentation and reassembly?) = I do find the text on transport modes somewhat confusing, U, M+U and MulticastListen+U. I'd like to see more descriptive text Abstract: = OLD: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP leaves some details unspecified or provides alternative options. Therefore, only profiles which specify those missing parts define actual implementable DNCP-based protocols. NEW: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses Trickle and Merkle trees. DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol. = The purpose of that change would be to make it clear what this is. A framework? A component that protocols can be built out of? = Add a reference to Merkle trees? Section 4.2: = This is confusing: o If using a stream transport, the TLV MUST be sent at least once, and it SHOULD be sent only once. OLD: * If only unreliable unicast transport is employed, Trickle state is kept per each peer and it is used to send Network State TLVs every now and then, as specified in Section 4.3. NEW: * If only unreliable unicast transport is used, Trickle state is kept per peer and it is used to send Network State TLVs intermittently, as specified in Section 4.3. s/every now and then/now and then/ s/employed/used/ Section 4.3: = reference to rfc6206? o the endpoint is in Multicast+Unicast transport mode, in which case the TLV MUST be sent over multicast. o the endpoint is NOT in Multicast+Unicast transport mode, and the unicast transport is unreliable, in which case the TLV MUST be sent over unicast. = What do an implementation do if the endpoint is not in M+U transport mode, and the unicast transport is reliable? (I do find the transport modes confusing, and I'm not sure I understand the MulticastListen mode). s/when using also secure unicast/when using secure unicast/ Section 4.4: = What is meant by: link with shared bandwidth? o Any other TLV: TLVs not recognized by the receiver MUST be silently ignored. = doesn't that mean it isn't stored in the Merkle tree? and the hashes don't compute? Section 4.6: = First mention of a topology graph. Section 5: == o Endpoint identifier: the 32-bit opaque value uniquely identifying it within the local node. = it? I think I'm still confused what is an endpoint, what is a peer and what is a node. o Range of addresses: the DNCP nodes that are allowed to connect. = How does a range of addresses look like and how is it used? I find only one occurence in the document. Section 6.1: A DNCP profile MAY specify either per-endpoint or per-peer keep-alive support. = Again I'm confused over the usage of endpoint versus peer. What's the difference between per-peer and per-endpoint keepalives? Section 6.2: s/actually uses/uses/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [homenet] 6renum redux [Routing protocol comparison document]
Brian, Much as I love MPTCP, it only helps TCP sessions. And it requires both hosts to be updated to be effective. IPv6 multi-prefix multi-homing requires both hosts to support it. which means transport fixes. Or fully operational shim6, which was conceived and designed for this exact problem. right. I tend to think that the problems of multi-homing, multi-endpoint, mobility, and renumbering are tightly coupled. you might need to expose some of this to the transport and applications. I have more hope of solving this at L4.5 or even L5 (I suppose talking about a “session layer” would get me banned from the IETF. ;-)), than at L3.5. to take the digression back to homenet; if we agree this is a problem for transport or above, then at least we can declare victory by claiming it isn’t our problem. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] 6renum redux [Routing protocol comparison document]
Much as I love MPTCP, it only helps TCP sessions. And it requires both hosts to be updated to be effective. IPv6 multi-prefix multi-homing requires both hosts to support it. which means transport fixes. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] MPVD requirments in homenet
Liang, what do you mean by multiple services? if you mean walled garden, the homenet architecture only has the following to say: It should be noted that some multihoming scenarios may see one upstream being a walled garden and thus only appropriate for connectivity to the services of that provider; an example may be a VPN service that only routes back to the enterprise business network of a user in the homenet. As per Section 4.2.1 of [RFC3002], we do not specifically target walled-garden multihoming as a goal of this document. cheers, Ole On 03 Mar 2015, at 10:30 , Liang Geng liang.g...@hotmail.com wrote: Hi all, I'm Liang from China Mobile, a recent follower of this community. Following a previous thread concerning the discussion of MPVD in Homenet on 3rd Feb, I personally think that certain use cases are quite well in line with the mif MPVD scenario. As homenet architecture provides autonomic network configuration in future multi-service, multi-homed environment, I think it is also a new challenge in terms of CPE management. My immature thought would be that MPvD may provide a promising model. May I propose the following problems for the list to see if it is worthy of some serious investigation, on which hopefully would be something interesting I could make a brief draft for further discussion (maybe in Dallas meeting)? Problems to be addressed 1. Use case of MPVD in homenet -Single ISP, multiple services (covers single/multiple CE router(s)) -Multiple ISP, multiple services (covers single/multiple CE router(s)) 2. The association of PvD and network configuration in homenet -Address configuration -Naming and service discovery For both, now thinking of a new PvD TLV which enables the association of certain configuration and PvD. Initial thought would be that no DHCP option extension is needed terms of HNCP based pvd coveying. Host and non-HNCP routers may refer to mif work on how pvd information is provided. ...more to be discussed and added Any comments would be extremely welcome. Best wishes Liang ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Roaming hosts [was: Routing protocol comparison document]
On 21 Feb 2015, at 16:06 , Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: The client is running a stub implementation of the routing protocol. I thought we already had decided we didn't require changes to the host? We don't *require* changes to the host. We propose optional host modifications that improve the user experience. exactly. you aren't going to have much fun with multi-prefix multi-homing without host changes anyhow. The chairs will correct me if I'm wrong, but I believe this is consistent with Homenet's charter. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Roaming hosts [was: Routing protocol comparison document]
On 21 Feb 2015, at 16:06 , Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: The client is running a stub implementation of the routing protocol. I thought we already had decided we didn't require changes to the host? We don't *require* changes to the host. We propose optional host modifications that improve the user experience. exactly. you aren't going to have much fun with multi-prefix multi-homing without host changes anyhow. Let me get this straight: So the proposal is that end systems will have to change their IPv6 address when it moves between wifi APs if it's a current end system, and in order to keep its address, it needs to start to speak HNCP? are you replying to the point I made? cause fully functioning MHMP requires host support (read MP-TCP/session layer) regardless of moving or not. with regards to a proposal I haven't seen one written up, but I don't think what your are stating is it. ;-) cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Mikael, Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Within the current framework to solve this problem with what exists today when it comes to clients, I would say we need either: 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the APs using the same SSID, so the SSID can have the same L2 domain. This would probably mean we want to increase MTU on the physical links to avoid fragmentation. Messy. Possibly we could advertise lower MTU on the wifi network to minimize fragmentation if we don't raise MTU. 2. We set up some kind of L2 switching domain between the APs. This would require VLAN support in the HGWs, and something to set this up with loop avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as control plane, that way we could possibly run the same IGP for both L2 and L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds like an understatement. Frankly, I don't know how to solve this without a lot of complication. why do you think this has to be solved at L2? We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? at least you can do: L3 - route injection (got a routing protocol there already, use it) L3.5 - SHIM6. not deployable L4/L5 - MP-TCP L5/L7 - MOSH cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
It means that every single device on a wired network is on a different subnet. Perhaps it doesn't cause any extreme harm, but it certainly makes managing and debugging the network harder, and it means that you can't have a layer two switch anymore. So the question I would ask is not is there a problem with this, because obviously there is, but rather is there a benefit to doing it this way. I am curious to know what you think the benefit is. I am not mandating that each and every device is in its own broadcast domain, I am however advocating that we leave the model that has been prevalent for 10-15 years at least, ie that a home gateway has a WAN port and 4 LAN ports, and these 4 ports are bridged. I'm saying the typical device should have 4-5 L3 ports. You're then free to connect one of these to your L2 switch if you so please. I would like my router-to-router links to not have a lot of hosts in them if I can avoid it. +1. there are very few shared media around anymore. I don't think I've ever been connected to a 10base5. why should the IP subnet model emulate a shared medium, when the physical topology is a star. wireless with security is also a star topology, with a unidirectional broadcast channel. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
It means that every single device on a wired network is on a different subnet. Perhaps it doesn't cause any extreme harm, but it certainly makes managing and debugging the network harder, and it means that you can't have a layer two switch anymore. So the question I would ask is not is there a problem with this, because obviously there is, but rather is there a benefit to doing it this way. I am curious to know what you think the benefit is. I am not mandating that each and every device is in its own broadcast domain, I am however advocating that we leave the model that has been prevalent for 10-15 years at least, ie that a home gateway has a WAN port and 4 LAN ports, and these 4 ports are bridged. I'm saying the typical device should have 4-5 L3 ports. You're then free to connect one of these to your L2 switch if you so please. I would like my router-to-router links to not have a lot of hosts in them if I can avoid it. +1. there are very few shared media around anymore. Still one to phase out: spectrum ;-) I would say the opposite, I see kids that have never been connected to a wired link. What about wireless repeaters, which forward packets and do not have a network jacket? Wireless backhaul links to ISP? yes, at L1 but not L2, which was what I was trying to say. citing 802.11 as an example. cheers, Ole Teco I don't think I've ever been connected to a 10base5. why should the IP subnet model emulate a shared medium, when the physical topology is a star. wireless with security is also a star topology, with a unidirectional broadcast channel. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenets and MPVD
Markus, All routers gather this information through HNCP and use it to configure hosts. DHCP options that are associated with a given delegated prefix are given to hosts associated with the link prefix provided by the prefix assignment algorithm. DHCP options that are not associated with a delegated prefix are aggregated and given to the host (Excepted for the DNS server option, as the router is used as DNS relay). DNS server option is mostly changed so we can do in-home service discovery. In MIF world, we would probably pass along DNS servers within PVDs as is, provide (e.g.) ‘.home’ PVD for in-home services only, and provide only to legacy clients the ‘relay’ DNS server address. So oddly enough, current scheme would work, most likely as-is ;) The unknown new PVD option would be passed along as is, and the clients would treat the provided legacy DNS server (+search path) as an extra implicit PVD with hopefully lower priority than the explicit PVDs. Not changing PVDs may be crucial if the PVD authentication ever takes hold, as changing it’s content then may make it altogether invalid from the client’s point of view. is it actually obvious that you'd pass the PVDs to the hosts in homenets? PVDs contain policy. and allowing them to pass the administrative boundary into a home is also up to policy. given that we already have options to control DNS server selection policy. why can't the home border amalgamate that information (according to local policy)? sorry, I'm struggling to understand the PVD use case I suppose. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenets and MPVD
PVD tell you also about the kind of connectivity available there etc. While I am sure we _could_ fabricate local one, it is much easier to tell that e.g. one upstream connection is pay-per-byte 4g, and other one is VDSL2 and let hosts make educated choices instead of guesses about source prefixes to use. One of the design goals of the PVD architecture is to make it possible to get the same behavior in a 4G handset with a Wifi interface and in a laptop with no 4G interface that's connected to a network with a 4G PVD and a wireline PVD. what behaviour is that? Is this covered somewhere elsewhere in the DHCP option jungle? A document is being worked on to address this, but no, it is not yet covered. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for Routing Protocol
Juliusz, you could also inject the route with a 3rd party next-hop pointing to L. cheers, Ole On 16 Nov 2014, at 10:54 , Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: If the latter, I can see some opportunities for transient routing loops if not done carefully. (And you certainly don't want a routing loop on a link with low-power nodes.) That’s interesting. Could you try explaining what could happen ? I hope I'm just being paranoid, since I rather like the idea of redistribution through HNCP. A and B are homenet nodes. L is a low power node. A-B \ / \ / L | | LLN A and B are both announcing the LLN route. L crashes. A and B both notice that L is no longer reachable, so each of them attempts to route through the other one. You have a transient routing loop that lasts until A and B agree on the fact that L is unreachable. On a wired network, the routing loop will be extremely short-lived (one successful packet exchange for both Babel and OSPF, not sure about IS-IS). I'm not sure what will happen on a wireless network, but I've learnt to be pessimistic about the behaviour of 802.11. I could imagine cases where the looping data traffic prevents A and B from communicating successfully, especially if L had more than just two Homenet neighbours. In the case of Babel (or EIGRP, for that matter), running a stub implementation on L solves the problem quite nicely, by allowing the loop-avoidance algorithm to kick in before the loop is established. With link state, you still get a transient loop, but you're relying on the carefully designed flooding algorithm of a mature routing protocol to clear it, rather than counting on the poorly understood interactions between the routing protocol and HNCP happening in the right order. -- Juliusz ___ 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
Re: [homenet] Next Steps for Routing Protocol
Michael, 1) pure peering - homenet - LLN ::/0 - LLN - homenet more specifics for LLN routes and cloud service prefixes I don't understand your ::/0 here. I think the LLN gets a ::/0 route into the homenet, and the homenet gets a specific route into the LLN. Is this what you were trying to say? homenet advertises a default into LLN. or LLN discovers a default from homenet. LLN advertises more specifics into homenet. for the pure peering case, I think it would be sufficient for the LLN to do router discovery (as a host) and for the homenet to provide some mechanism for the LLN to register which routes it should advertise for it (aka buddy routing). that mechanism please inject these routes for me, would most likely not require participation in a routing protocol, nor have stringent requirements for convergence, dead neighbour detection. we may possibly think of them more as static routes. Right, I think we should have this... I also think it simplifies how things like virtual machine systems might work; HNCP gets them a prefix, and they are always a stub network too. the LLN may not get a prefix from the homenet. that depends. the LLN may make up its own from ULA, or it may get one from LLN cloud provider. the LLN could even number the homenet. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for Routing Protocol
While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was proposed that the IoT device domain would never be used for transit so it only needed to get a default (or other aggregate) and inject a prefix and the HNCP could be made to satisfy this requirement. Could you please clarify what you mean by inject a prefix in this context? Stub router sends HNCP message to non-stub router asking it to perform redistribution? When does the non-stub router cease redistributing? indeed. there are quite a few unknowns here. on the Thursday meeting I think we jumped too early into making assumptions on solutions before understanding the requirements. from speaking to James, I can at least see the variants for homenet to LLN peering: 1) pure peering - homenet - LLN ::/0 - LLN - homenet more specifics for LLN routes and cloud service prefixes 2) peering + homenet numbered from LLN 3) peering + LLN numbered from homenet as soon as there is a requirement for one of the networks providing prefix assignment to the other, some variant of HNCP is required in addition to some form of peering routing relationship. for the pure peering case, I think it would be sufficient for the LLN to do router discovery (as a host) and for the homenet to provide some mechanism for the LLN to register which routes it should advertise for it (aka buddy routing). that mechanism please inject these routes for me, would most likely not require participation in a routing protocol, nor have stringent requirements for convergence, dead neighbour detection. we may possibly think of them more as static routes. while 2 and 3 require participation in HNCP, my worry is that even HNCP is too chatty for the LLN to deal with. do we have any numbers? presumably one could design a stub HNCP, where the peer only received messages relevant to it, possibly even with a HNCP sleep proxy. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Next Steps for HNCP
Pierre, while 2 and 3 require participation in HNCP, my worry is that even HNCP is too chatty for the LLN to deal with. do we have any numbers? presumably one could design a stub HNCP, where the peer only received messages relevant to it, possibly even with a HNCP sleep proxy. We could try to make HNCP more Low-Power-friendly, but there will always be cases where HNCP will kill LP nodes because HNCP provides network-wide state synchronization (e.g. a buggy node keeps sending changing updates). IMO, the reason why the ‘buddy’ approach was relevant for Low-Capacity devices like James’ is that HNCP could be useful for different things (e.g. advertise a Delegated Prefix), which we can’t really do with a routing protocol. So instead of having HNCP + RP, it would be HNCP alone. In which case the chattyness of HNCP doesn’t matter much. That said, I think the chatyness of both HNCP and the RP should be taken into account, as a ‘weak' requirement (i.e. it should not override already existing requirements). I think we need to separate the two discussions. let's start a separate work item for peering with LLNs. Additionally, I **don’t** think the WG should consider defining a full HNCP-proxying mechanism. If HNCP is successful, and if the need appears to be strong, OK. But we should make something that works without such support first. Proposal #1 is, IMO, a correct trade-of. if proposal #1 is for peering with LLNs I don't think that's correct. firstly we need to get the requirements better defined. and by the way overloading the assigned prefix TLV as a register external route option is pretty ugly. you'll then get assigned prefixes which aren't even more specifics out of the delegated prefix. keep the prefix assignment mechanism clean please. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
What does flow-through PD mean? Do you have any reference on that? It means that the edge router has the delegation, and then sub-delegates individual /64s from the pool of /64s it was delegated by the ISP, rather than splitting its delegation and delegating chunks of that delegation to downstream routers which will then delegate in turn. In order for this to work, downstream routers have to relay PD requests to the edge router, and install routes to the delegated prefixes. Something analogous could work on an autonomous network; I don't know that it's the right way to solve the problem, but it's certainly one way to solve the problem. Homenet went with HNCP because it's more sensitive to arbitrary topology changes. The hierarchical model doesn't work because it doesn't anticipate new routers being added to the network, and doesn't account for unbalanced topologies. I thought the hipnet proposal wound up going with the flow-through model, not the hierarchical model, but I may be mistaken. I think the homenet wg did a good of analysing the 3 variants proposed. the flow-through model as far as I can recall suffers from DHCP's general problem of dealing with multiple sources of information (think multihoming with separate CE routers), in addition you either need to build what's essentially a spanning tree of DHCP relays or you need some mechanism to discover the set of DHCP server(s). certainly do-able, but not quite out of the box. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15
Ted, the flow-through model as far as I can recall suffers from DHCP's general problem of dealing with multiple sources of information (think multihoming with separate CE routers), in addition you either need to build what's essentially a spanning tree of DHCP relays or you need some mechanism to discover the set of DHCP server(s). certainly do-able, but not quite out of the box. Actually it doesn't suffer from this problem. You just wind up getting a prefix delegation per edge router, and when you get a delegation, you add that edge router to the list of routers to which you will relay downstream prefix delegation requests. You do not need spanning tree because if you reach the same router through two different paths, you will just get the same delegation twice per DUID/IAID. The reason homenet didn't go with this solution is essentially that HNCP has a better feature set and is easier to make work in a homenet environment. (To be clear, I am just explaining the prefix delegation model. If Anima doesn't want to do it that way, that's fine with me, just as it's fine with me that homenet went with HNCP.) it isn't as obvious as you make it out to be. there is no point in us arguing over that here (we have had this exact argument previously), write a draft if you think the flow-through model is viable in a network with multiple edges and arbitrary topology. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)
Fred, https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-routing-extra-qualifiers/?include_text=1 https://datatracker.ietf.org/doc/draft-lamparter-rtgwg-dst-src-routing/?include_text=1 Speaking strictly for myself, I’m not sure why homenet is relevant. The technology is related to networks that have different routing depend on on one’s use case. A class of solutions for it has been called the “fish” problem, and built using multi-topology routing. In homenet, it’s called SADR, and is primarily about egress routing (routing to an egress to an upstream ISP that gave you a PA prefix). While one doesn’t really want to confuse theory with practice, in theory it could be used between points of a network, to prevent folks using one set of prefixes to talk with another set, or to force routing of some sessions in some ways. Personally, those are a class of problems I associate with campus networks more than residential networks. why homenet is relevant? isn't multi-prefix multi-homing one of the most obvious use cases for source address dependent routing? that's not restricted with homenets, but also any small network. I'm assuming large networks will continue with PI addresses and BGP based multihoming. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DHCP PD
Ted, actually, we're talking about prefix assignment. which may be splitting hairs, but isn't quite the same as prefix delegation. Splain? You mean we're talking about the general problem, rather than the DHCP-PD solution? If so, that's fine, but the specific comment that Markus made was about DHCP PD, and that's what I was responding to. I am not specifically advocating the use of DHCP PD to solve this problem, but I do want to see it evaluated realistically, and not on the basis of a misunderstanding of what it does and how it's used. as one of the authors of RFC3633, DHCP PD was not designed to do assignment of prefixes inside a network. DHCP PD was designed to be a fax replacement. there has been a number of proposals for how DHCP PD could be adapted for this purpose: they generally fall into one of flat assignment with central DHCP server or hierarchical PD with a spanning tree of DHCP relays. http://tools.ietf.org/html/draft-baker-homenet-prefix-assignment-01 http://tools.ietf.org/html/draft-chakrabarti-homenet-prefix-alloc-01 http://tools.ietf.org/html/draft-gmann-homenet-relay-autoconf-01 http://tools.ietf.org/html/draft-grundemann-hipnet-00 please take a look at those drafts, and let us know what we've missed in the DHCP PD solution space. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DHCP PD
Ted, you make it sound like that's a part and parcel of DHCP. I can't see how you can implement that today. Eh? It's dead trivial. The draft already sets up relay agents—the only difference is that all relays now relay to both CERs, not just one. The requesting routers get delegations from both CERs and use both delegations. you cut out my question about how to build the relay topology. e.g. relays would have to replicate client messages to multiple CERs. You are right that no existing implementation does this, but no existing implementation does homenet, so that seems like a pretty mild criticism! :) a goal for homenet is to reuse existing implementations. homenet routing protocol server? this proposal makes do with static routing. When I said the proposal looked mostly right, I was referring to the DHCP PD aspect, not the static routing aspect. Static routing might work, but I suspect it would be brittle. how do you deal with multiple routers on the link? just keep adding /64s out of the same site-prefix to it? Only the CERs delegate prefixes. If you have multiple paths to the same CER, you will still only get one prefix per identity association. a link with multiple routers on it will get multiple prefixes from the same site prefix. how does the network react to network events? given you rely on DHCP snooping then network convergence time is rather glacial. Right, I'm not arguing that we don't need a routing protocol. I'm not even particularly arguing that PD is the right way to delegate prefixes. But it would work, and with no protocol changes—it would just require an operations document to explain how to do it. I see you are making that assertion. I don't believe you. please write a draft how this would work. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DHCP PD
Given N*10^8+ (conservative estimate, N some single digit probably) potential homenet hosts already out there and 0 homenet routers, designing with the assumption that ‘yeah, hosts can change’ doesn’t sound too reasonable to me. Then again, what’s wrong with fighting windmills? We're talking about prefix delegation. Prefix delegation runs on routers, not hosts. actually, we're talking about prefix assignment. which may be splitting hairs, but isn't quite the same as prefix delegation. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
7) I generally despair of this entire debate, and wish more people were writing code, doing experiments, and working inside the real world. I hate that this discussion has ratholed on the method of distribution, rather on than on what configuration information needs to be propagated inside the home on zigbee, wifi, lte, moca, homeplug, in order to have grandma be able to get her pr0n and meds from her high-tech wheelchair. apart from the sentence making it appear that configuration information hinges on data-link type, I think you make an important point. what information needs to be propagated in the home? since this is the homenet working group, we limit ourselves to getting the network layer functional. that in my mind is: addressing, unicast routing, service discovery, external naming, other host configuration, and time. unicast routing: - internal routes (assigned /64s and ULA) - SADR routes for PD prefixes (either explicit SADR or implied as part of prefix assignment) - More specific external routes (learnt via RFC4191 or other configuration) requires explicit SADR addressing: - PD prefixes - ULA prefixes - whatever assigned prefixes required for the prefix assignment algorithm to function - meta data associated with prefixes (SAS/DAS policy, colour) service discovery: - DNS zones for the bootstrapping the mDNS scheme external naming: - I don't see how we can make this zero-conf. each border router could run hidden primaries for the reverse zone. if you get forward zones from the ISPs, then applications could update each of those primaries using DNS update. assuming we can bootstrap security. if the home has a vanity name, then the hidden primaries must run on some well known address in the home, and there has to be some agreement with either ISP or someone else to run secondaries. other host configuration: - this is information learnt from external connections, homenet defaults and configuration provided by the user. basically externally learn from RA/DHCP, and passed transparently through the homenet, for homenet routers to propagate to hosts using DHCP/RA - DNS recursive resolvers - DNS server selection policy - SAS/DAS policy - NTP servers - whatever else is required for configuration of the network layer we could put these into three different classes: 1) addressing / routing 2) configuration information for the homenet routers 3) configuration information for hosts (that the homenet passes transparently from some source to hosts) addressing and routing are inherently tided together. the home network is quite useless without either of them functioning. if we look at a routing protocol as just a distributed database, it might not matter what we put into it, although it makes my tummy churn to think about embedding DHCP options into OSPF. ;-) cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
You (and others) who speak of a Homenet Configuration Protocol seem to be making an assumption which is far from clear to me. That assumption is that config parameters in a homenet will come in some sense top-down from a higher level source of authority. No, I don't think that's what's assumed. All the discussions I've heard have been to have configuration sent around the home using a routing protocol, or another protocol that disseminates information around the home in a similar fashion. absolutely. any protocol here must support multiple sources of information. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Teco, My opinion: put the prefix distribution protocol on top of NDP, so all nodes are informed. what are the arguments for involving hosts in the prefix assignment protocol? as opposed the existing router to hosts protocols (ND/DHCP). With multiple prefixes, hosts have to select. yes. there isn't that much information the network has that it can tell hosts though. as long as the network routes the packets the right way, I'm going to be happy. in more convoluted networks with walled gardens and VPNs, the network may pass the host more policy information, e.g. DNS server selection, SAS/DAS policy and so on. Hosts get smarter and know how to handle multiple paths (MPTCP and the like). It isn't enough just to provide a prefix with lifetime. If the router knows more, for example data rate and delay (fixed line, 3G/4G, whatever), it shall pass it to the host. as the hosts gets smarter they'll be able to figure out the best end to end path themselves. the network may pass meta data associated with prefixes to the hosts. e.g. usage of this prefix is horribly expensive. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Teco, I can see reasons for having shared sub-layer for routing protocol and prefix distribution protocol. As example, in MANET we have such already: RFC 5444 and 5498. If we define a set of TLVs for border router information and prefix distribution, it can run on whatever routing protocol. Don't forget BGP. For Homenet plugplay, I don't suggest to let configure grandma her favorite IGP ;) doesn't that mean we have to pick one? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
I can see reasons for having shared sub-layer for routing protocol and prefix distribution protocol. As example, in MANET we have such already: RFC 5444 and 5498. If we define a set of TLVs for border router information and prefix distribution, it can run on whatever routing protocol. Don't forget BGP. For Homenet plugplay, I don't suggest to let configure grandma her favorite IGP ;) doesn't that mean we have to pick one? At least one, for Homenet. Could be OSPF for high speed links, RPL for LLN, or OLSRv2 for mix of wireless and wired links including ad hoc radio links. There is something common on prefix distribution in Homenet, small office/home office networks, branch office networks, ad hoc networks and even in enterprise / campus networks. The prefix distribution protocol could be a single protocol. We better not try to converge to a single routing protocol. how do you do a self-organizing / zero-conf network without making a choice? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Teco, There is something common on prefix distribution in Homenet, small office/home office networks, branch office networks, ad hoc networks and even in enterprise / campus networks. The prefix distribution protocol could be a single protocol. We better not try to converge to a single routing protocol. how do you do a self-organizing / zero-conf network without making a choice? I ment: We better not try to converge to a single routing protocol for Homenet, small office/home office networks, branch office networks, ad hoc networks and enterprise / campus networks. OK, but at least we can pick a single routing protocol for the home. If distributed info semantics for prefix distribution are well defined, it doesn't matter how it is delivered. Single encoding method helps, it is not absolutely required. If a box faces two routing domains, it redistributes. With DV style of flooding, this is simple and straightforward. right. but we don't have to specify that in this working group, or at least not now. I still believe hosts shall be informed of information on border routers / exit links and corresponding prefix information. And I prefer hosts shall not have a need to snoop routing packets for that. Using a NDP extension is a no-brainer for me. So yes, Homenet shall select a single routing protocol for higher data rate links (next to LLN routing, that one is separate). We can check how to run a prefix distribution protocol on top of routing, or use another carrier (e.g. NDP). My opinion: put the prefix distribution protocol on top of NDP, so all nodes are informed. what are the arguments for involving hosts in the prefix assignment protocol? as opposed the existing router to hosts protocols (ND/DHCP). cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] DHCP PD (was: Homenet protocol decisions)
Alex,
changing the thread since this seems to diverge from getting answers to the
questions I asked.
cheers,
Ole
On 30 Jan 2014, at 13:55 , Alexandru Petrescu alexandru.petre...@gmail.com
wrote:
Pierre,
Thanks for the reply.
Le 30/01/2014 13:46, Pierre Pfister a écrit :
Le 30 janv. 2014 à 13:38, Alexandru Petrescu
alexandru.petre...@gmail.com a écrit :
Le 30/01/2014 13:28, Ole Troan a écrit :
Could it be separate (existing) protocol?
if one had existed, sure. requirements from homenet-arch (I
might have missed some): - must support multi-homing - each
link should be assigned a stable prefix - efficient
allocation of prefixes - should support both IPv4 and IPv6
I meant this:
loosely coupled separate (existing DHCPv6-PD) protocol
triggering route updates to the routing protocol.
yes, DHCP PD comes up as a proposed solution quite frequently. I
just don't see how you can make DHCP PD fulfill the
requirements.
Well it does support multi-homing (Server allocates things to as
many interfaces as needed), each link can be assigned a stable
prefix (provided it triggers updates to the Routing protocol), the
allocation is efficient (Server maintains dynamic databases,
leases) and it supports both IPv4 ('IPv4 subnet allocation'
RFC6656, DHCP transition et alia), and IPv6.
I miss something?
Well, in some cases DHCP seems to work, but not when you start
imagining multi-homed networks with multiple routers. Or maybe you
can tell me how to solve this situation with DHCP:
You have ISP1 connected with Router 1. ISP2 connected with Router 2.
Router 1, Router 2, and a third Router (Router 3), are connected on
the same link. ISP1 is delegated the prefix A/56 to Router 1. ISP2
is delegating the prefix B/56 to Router 2.
A host is connected behind Router 3.
Bear with me for a moment... is this topology what you meant?
ISP1 ISP2
| |
+---+ +---+
|Router1|A/56 |Router2|B/56
+---+ +---+
| |
--+---+--+--
|
|
+---+
|Router3|
+---+
|
++
|Host|(how can it get an address from A, and from B)
++
How can it get addresses from both prefixes ?
Before I try to figure it out - is the above topology what is meant?
Something I misplaced?
Alex
Cheers,
Pierre
Alex
cheers, Ole
___ homenet mailing
list homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
I would like to clarify what is meant by distribution of other configuration information? We're all talking about distributing prefixes, but what about SIP and similar configuration parameters? In my opinion, it's not something I would like to see being distributed in OSPF/IS-IS. It's just not something routing protocols should be doing. by other configuration information I was thinking of two types of information: - information that is required by the other routers in the home network. e.g. zone information required for hybrid mDNS proxies - information that is passed around to the routers, and then passed on to the hosts using RA or DHCP: e.g. DNS recursive resolvers, DNS server selection policy, SAS/DAS selection policy I think there is an important 'scoping' here. the mechanisms here should be used to configure the function of the routers in the home network, and pass information to the hosts to configure the _network_ layer. I don't quite see how you can (or should) configure applications this way. cheers, Ole That being said, the alternative option is to define a new protocol... Over the last year, I've been playing with the idea of a protocol that uses the DNS idea of recursion (and discussing it with a couple of people). Let me clarify with the example of a SIP server: 1. we have a SIP server at the ISP 2. my home has 7 cascaded HGWs and none of them know the address of the SIP server 3. I want to connect my analogue phone to the sixth HGW and so this HGW needs to find out the SIP server address - he therefore asks his upstream HGW (the fifth in line) for it (of course, using this new and fancy protocol) 4. the fifth doesn't know it and asks the fourth, the fourth asks the third, etc. 5. the first one (the one connected to the ISP) gets the request and requests the ISP via DHCPv6 for it 6. upon receipt, the first forwards the information to the second, the second tells the third, etc. until the 6th receives it and then I can use my phone This approach would have to be worked on (what about multiple upstream links, routing loops?), but I like it. It could be extended to support the delegation of prefixes, active detection of border HGWs (when do you send out DHCPv6?)... Any thoughts? Branimir On Thu, Jan 30, 2014 at 2:18 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Thu, 30 Jan 2014, Ole Troan wrote: We need to decide, if we want prefix assignment and distribution of other configuration information integrated in a routing protocol. Depending on that decision we either need to design a separate protocol to do that, or we need to add support for that in a routing protocol. Prefix assignment is simpler with a link-state protocol, so that's why I have limited the choice of routing protocols for that branch. I have assumed there is agreement to have a single routing protocol in the home, and not support multiple. I agree with the decision chart. While I initially was very enthusiastic about integrating prefix assignment into a routing protocol, I am now more sceptic to this approach. So question if we don't use the routing protocol for prefix assignment, what should go in there? Should we have a new protocol for service discovery? Topology discovery? Anything else? Anyhow, the src/dst enhancements for the IGP has to be done, I don't see much alternative to that. Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to interfaces. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet protocol decisions
Dave, 1) in the multi-homing case you want requests from a local dns server to be sourced from the right network to the right ISP-provided forwarder. (think I have a fix for that but it involves abandoning resolv.conf for specific dnsmasq configuration. I can't quite see how you can do that. given that typically the DNS lookup is done prior to the choice of source address (choice of outgoing link). RFC6731 specifies a policy that can be distributed to hosts. (which would typically go in a homenet protocol). it is unfortunate that in some VPN / walled garden scenarios there are split DNS, if it wasn't this wouldn't have been a problem. I'm unsure what the right answer is with regards to using recursive resolvers outside of your own administrative domain. DNS forwarders make an attractive target for surveillance. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
Juliusz,
there is also a draft: http://tools.ietf.org/html/draft-troan-homenet-sadr-00
an implementation using Linux table support will require duplication of route
entries into multiple tables.
cheers,
Ole
On May 7, 2013, at 14:03 , Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
If you're actually doing source-specific routing, please show me how
you speak to the kernel.
Most of that code is in Lua, and while I could have included
C extension module that did similar things as ip -6 does, I didn't
bother.
We're doing pretty the same in our prototype code (saying
system(ip...) rather than speaking the netlink dialect of the day).
Could you point us at the relevant code, please?
So I'm just using ip -6 {route,rule} to set up source-specific rules
that map to destination tables.
Ah, okay. So you're using rules, just as we found out (the hard way)
that we need to do.
http://www.spinics.net/lists/netdev/msg235316.html
http://www.spinics.net/lists/netdev/msg235346.html
One (destination-based) routing table is maintained by routing
protocol, and the rest by Lua code which figures external defaults
based on routes within routing protocol implementation.
Nice hack.
-- Juliusz
___
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
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
[...] We have switched to RA-Handling in userspace for similar reasons already so I guess it's only the next logical step to create separate routing tables for each upstream interface to do source-based routing and filter out ULA-traffic on this layer instead of through iptables. don't do it per upstream interface, that wouldn't work. per next-hop might. the draft suggests a single table with source constrained routers and backtracking. Having one central userspace management daemon for routing and address / prefix delegation in general might not be the best or cleanest solution in the end but I guess there is no better way right now. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Source-specific routes in Linux [was: atomic updates...]
[...] We have switched to RA-Handling in userspace for similar reasons already so I guess it's only the next logical step to create separate routing tables for each upstream interface to do source-based routing and filter out ULA-traffic on this layer instead of through iptables. don't do it per upstream interface, that wouldn't work. per next-hop might. the draft suggests a single table with source constrained routers and backtracking. Having one central userspace management daemon for routing and address / prefix delegation in general might not be the best or cleanest solution in the end but I guess there is no better way right now. cheers, Ole ___ 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
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Teco, [...] I don't think the homenet should get into the policy part of this, but rather just provide some simple tools/infrastructure. Hmm. I also prefer simple tools/infrastructure. But let's try to solve some problems, or at least we shall not block solving later on. are the problems clearly understood at this point? written down? I agree SADR is a major part of the right solution. Source address indicates the provision domain, at least for IPv6. Hosts need to be updated and mif should take the lead here. But mif only can take the job if the network supports multiple provisioning domains well, e.g. SADR. Updated hosts need SADR as well. I've always seen SADR as a network function. hosts would do RFC6724. SADR on hosts is used quite often, where redundant links are in place. that's not SADR. SADR is about _forwarding_ of packets. [...] Back to the draft-ietf-homenet-arch WGLC: this provisioning domain topic is not addresses very well. Question is if we will address it, hand it over to mif, or cooperate where we focus on the (plugplay) network part and mif takes the hosts. I think we have a fair idea of how to deal with the home network being multi-homed. i.e. two or more connections to the Internet. we also have a decent idea of how to deal with multi-homing to non-congruent networks, see draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-05 I'm not quite sure what problem multiple provisioning domains is trying to solve outwith that. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Teco, Still I am puzzled how we can support multiple provisioning domains with multi-addressed hosts in a homenet. May I reference to the discussion in mif? http://www.ietf.org/proceedings/86/slides/slides-86-mif-1.pdf For providing information on provisioning domains, we might look into DHCP _and_ ND. I think both can and should be supported. I think one of the problems is how to merge or multiplex information from/for these provisioning domains. Has DHCP a kind of ProvisioningDomain_ID on each (serf of) data element(s)? On SAS/DAS policy, how to create such automatically in network elements? If we can't on the fly, it might be irrelevant for homenet. unmanaged and policy are at different ends of the scale. I don't know how you can do anything automatic with that. in the homenet prototype I was talking about we implemented draft-bhandari-dhc-class-based-prefix-04. where we attached a colour to each address prefix. this could then be used as a handle for SAS/DAS or for the application. I don't think the homenet should get into the policy part of this, but rather just provide some simple tools/infrastructure. I agree SADR is a major part of the right solution. Source address indicates the provision domain, at least for IPv6. Hosts need to be updated and mif should take the lead here. But mif only can take the job if the network supports multiple provisioning domains well, e.g. SADR. Updated hosts need SADR as well. I've always seen SADR as a network function. hosts would do RFC6724. there would be some gain in being able to signal hosts with routing information. not sure what that should be, unless we would just have hosts participate in the IGP. And of course the legacy stuff is out there. Re-reading sections on multihoming (3.2.4, also 3.4.4), there is enough room for solution space. I would expect some more guidelines form an architecture, but now there are no constrains on what we may work out. That's fine. May I suggest to add MPTCP (RFC 6824) at bottom of 3.2.4? agree. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07
Teco, Reading the homenet-arch, I can't find how multi-addressed hosts are guided to prefer one address over another. I think such facility is beneficial in multi-homed homenets. the intention is to propagate the SAS/DAS policy given with draft-ietf-6man-addr-select-opt, and more specific routes learn on the border, combined with source address dependent forwarding. as well as rule 5.5 of 6724. that's in solution space though. there is already a reference to the multihoming-without-ipv6nat document. do you have ideas of anything else we should add to the architecture document? cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Naming and Service Discovery
My understanding was that they were going to extend mDNS to work on multiple segments, rather than gluing mDNS islands with DNS... but I have not really followed the discussions in the mdnsext. see: http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion
Fred, Ole Troan and Lorenzo Colitti documented their model, which is strictly egress routing based on the OSPF AS-prefix-LSA and the assumption of automated prefix allocation. This is not multi-topology; it in effect tags the default route advertised as a route from an alternate universe. http://tools.ietf.org/html/draft-troan-homenet-sadr IPv6 Multihoming with Source Address Dependent Routing (SADR), Ole Troan, Lorenzo Colitti, 18-Feb-13 to clarify, the SADR draft: - describes what source constrained / source address dependent routing is - describes a conceptual forwarding model - gives two alternatives to how a routers forwarding table can be populated. a) implicitly via other information learn from the prefix assignment protocol b) explicitly via one of the Baker extensions to routing protocols. neither a nor b has any restriction to just the default route. more specific routes are supported too. b allows flexibility to also advertise internal (S,D) routes, and S,D routes not associated with border routers. I specifically chose single topology. just to make it clear, I think the correct solution is to add support for (S,D) routes in the routing protocol, I just don't want to sit on the fence and wait until that support is added and available. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
Ray, [...] 2. Aren't we forgetting the first hop? Given a shared subnet/prefix/link with 2 CPE routers performing some fancy new form of forwarding (based on PBR or SADR or whatever) that is also shared by existing host implementations, how will the routers signal these new default route semantics to end hosts? Would we need a new prefix information option in ND? Would we need an extension to RFC 4191 Section 2.3 Route Information Option to include (source prefix,destination prefix) routes? Would we need a new ICMPv6 redirect message to extend RFC2461 Section 4.5 to include the possibility of (source,destination) redirects? The beauty of this approach is that you don't need to signal anything to the hosts for things to work properly. The hosts pick whatever source address they choose and the network takes care of getting the packet to the right exit. Don't understand. Maybe I'm being really dumb. What about figure 2 of the Homenet Architecture? fixed width +---+---+ +---+---+ \ | Service | | Service | \ | Provider A | | Provider B | | Service |Router | |Router | | Provider +--++ +---+---+ | network | | / | Customer| / | Internet connections | / | | +--++ +---+---+ \ | IPv6 | |IPv6 | \ | Customer Edge | | Customer Edge | \ | Router 1| | Router 2| / +--++ +---+---+ / | | / | || End-User ---+-+---+---+--+--+--- | network(s) | | | | \ ++-+ +-++ ++-+ +-++ \ |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / | H1 | | H2 | |H3| |H4| / +--+ +--+ +--+ +--+ Figure 2 /fixed width IPv6 Host H1 will receive RA messages from R1 and R2, and add them both to the default router list (RFC2461 6.3.6). IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with autoconfiguration and on-link flags set, and configure /64 prefixes from both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these as being on-link. But IMHO there's no further AS number/provider information/upstream topology information coupled to these /64 prefixes. There might be a router-router interconnect LAN between R1 and R2, or there might not be. if there is no interconnect between R1 and R2, then the host has two interfaces connected to two separate connections. then I can't see how that can be solved in the network. my assumption is that all homenet routers must be connected (I see I haven't stated that anywhere, but that should be added). How will the host H1 know to associate source address prefixes from provider2 with router2 for off link destinations e.g. to a Provider2/56 or Provider2/32? in your case it will RFC6724, rule 5.5 My expected host behavior would currently be that it'd just choose one of the known available default routers from the list. If correct fine. If not, then wait for an ICMPv6 redirect to be told to use the other router. you would only get that if the routers were connected of course. whichever came first, you'd either get a unreachable code 5 (wrong source) or ICMP redirect, or the router would just forward the packet to second router. But the ICMPv6 redirect doesn't have any facility to include source prefix specific info: only a redirect for a destination prefix to use another router (for all source prefixes), not for a source/destination pair. In the situation depicted in Homenet Arch figure 2, there will almost certainly be two valid routes to e.g. www.google.com, one via each provider, with the correct 1st hop router dependent purely on the source prefix. I agree, there is nothing useful the host learns from an ICMP redirect here. Even with RFC4191, the extension only provides routing information for a host to be able to select a default router based on the destination prefix, not an associated source prefix. Are we saying that H1 should tightly couple source address selection with RA PIO default router selection? for directly connected hosts, we have that already. note that only applies when hosts are connected to the border router. Thus H1 should never send packets with a source
Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt
Ray, thinking out loud. the border router includes in the advertisement of the aggregate prefix: - it's own global IPv6 address - list of external routes each internal router: - installs (S,D) routes for all of the external routes with the border's global as next-hop. normal unicast routing is used to get to the border. yep, that should work too. and be completely independent of routing protocol. but at the cost of being dependent on the prefix assignment mechanism. leaving the question open I suppose, does SADR have a wider applicability outside of the home network... cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt
Begin forwarded message: From: internet-dra...@ietf.org Subject: New Version Notification for draft-troan-homenet-sadr-00.txt Date: February 18, 2013 22:01:47 GMT+01:00 To: o...@cisco.com Cc: lore...@google.com Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no with POP3 (fetchmail-6.3.20) for otroan@localhost (single-drop); Mon, 18 Feb 2013 22:02:13 +0100 (CET) Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 2013 15:01:50 -0600 Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 + Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com [72.163.7.178]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IL1ixR029679 for o...@cisco.com; Mon, 18 Feb 2013 21:01:49 GMT Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com with ESMTP; 18 Feb 2013 21:01:49 + Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 13:01:47 -0800 (PST) Authentication-Results: rcdn-inbound-i.cisco.com; dkim=neutral (message not signed) header.i=none X-From-Outside-Cisco: 64.170.98.30 X-Ironport-Anti-Spam-Filtered: true X-Ironport-Anti-Spam-Result: Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM X-Ironport-Av: E=Sophos;i=4.84,690,1355097600; d=scan'208;a=89740088 X-Virus-Scanned: amavisd-new at amsl.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Test-Idtracker: no X-Ietf-Idtracker: 4.40 Message-Id: 20130218210147.7330.45442.idtrac...@ietfa.amsl.com Return-Path: internet-dra...@ietf.org X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com X-Ms-Exchange-Organization-Authas: Internal X-Ms-Exchange-Organization-Authmechanism: 10 Mime-Version: 1.0 A new version of I-D, draft-troan-homenet-sadr-00.txt has been successfully submitted by Ole Troan and posted to the IETF repository. Filename: draft-troan-homenet-sadr Revision: 00 Title: IPv6 Multihoming with Source Address Dependent Routing (SADR) Creation date: 2013-02-18 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt Status: http://datatracker.ietf.org/doc/draft-troan-homenet-sadr Htmlized:http://tools.ietf.org/html/draft-troan-homenet-sadr-00 Abstract: A multihomed network using provider aggregatable addresses must send the packet out the right path to avoid violating the provider's ingress filtering. This memo suggests a mechanism called Source Address Dependent Routing to solve that problem. The IETF Secretariat ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt
David, thanks for the thorough comments. nice to see this moving forward! Comments below with section copy/paste. On Mon, Feb 18, 2013 at 10:04:45PM +0100, Ole Troan wrote: Subject: New Version Notification for draft-troan-homenet-sadr-00.txt [...] Filename:draft-troan-homenet-sadr Revision:00 Title: IPv6 Multihoming with Source Address Dependent Routing (SADR) Creation date: 2013-02-18 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt Status: http://datatracker.ietf.org/doc/draft-troan-homenet-sadr Htmlized:http://tools.ietf.org/html/draft-troan-homenet-sadr-00 4. Using SADR for multihoming SADR is similar to policy based routing. This memo proposes a simple extension to the destination based longest match algorithm to constrain it to source address. In order to support ingress filtering by upstream networks, the network MUST treat external routes specially. Ingress filtering MAY also be used internally, by installing (S,D) routes for locally assigned prefixes, where the source prefix would be the aggregatable prefix. If no ingress filtering is performed inside the network, then normal non-source constrained forwarding is used. The last sentence seems to imply that, unless we have ingress filtering on Internal Routers, they don't use SADR forwarding. This doesn't seem correct, shouldn't internal routers always use SADR to reach the correct border router? There is probably just a for local networks missing before the last full stop. yes, let me fix that. 6.2. Simplified SADR in home networks (In general, I'm not sure this simplified variant is a good idea... but I don't have an opinion yet at this point.) yes, it is a hack. it would allows us to proceed while waiting for SADR support in routing protocols though. In a home network using a dynamic prefix assignment mechanism such as [I-D.arkko-homenet-prefix-assignment] it may be known that a particular Border Router is announcing both an External Route and a Usable Prefix (for example, if the same router ID is announcing both). In this case, interior routers may assume that the Acceptable Source Prefix of the External Route announced by that Border Router is in fact the Usable Prefix announced by that Border Router. the sounds like a Border Router will only ever announce one such Usable Prefix. Thinking of DSL/Cable routers with an USB UMTS/LTE dongle, this isn't sufficient. An internal router when receiving a AS-External LSA route will install that in the routing table as normal. When the internal router receives a usable prefix as part of prefix assignment, the router shall add source constrained entries to all the AS-External routes received from the same border router (matching router-ID). To address aforementioned issue, this should probably read: An internal router when receiving a AS-External LSA route will install that in the routing table as normal. When the internal router receives one or more usable prefixes as part of prefix assignment, the router shall add source constrained entries to all the AS-External routes received from the same border router (matching router-ID), for each of the usable prefixes. yes. (Wording in arkko-homenet-prefix-assignment was changed from usable prefix to aggregated prefix by the way) Routes that are not associated with a border router or are not AS- External do not have source constrained paths. The routing protocol requirements for simplified SADR in the home network are: 1. Routing protocol must flood all information to all routers in the home network. (Single area). 2. Prefix assignment and unicast routing must be done in the same protocol. 3. A router must be uniquely identified (router-id) so that router advertisements and prefix assignment can be tied together 4. All routers on the homenet MUST support simplified SADR routing. I suppose that requirement applies generally, not only to the simplified variant. If 4. is not given, this scenario will lead to a loop: All links assumed at equal cost, r2 does not support simplified SADR, R1,R3,R4 do. ISP_A, pfx_A ::/0 ISP_B, pfx_B, ::/0 || R1 -- r2 -- R3 -- R4 | Host Host now selects an address from pfx_B to reach some site on the internet. R1 forwards to r2 because the ::/0 from R4 is more specific on the source. r2 forwards back to R1 because it didn't consider source specific-ness and just went by lower cost... In particular, as long as R4 doesn't advertise full SADR LSAs, this will also break if r2 implements full SADR, but not the simplified variant. yes, absolutely. cheers, Ole
Re: [homenet] prefix assignment on home networks
Mikael, Given that we want multiprefix multihoming with multiple prefixes, SADR is pretty much the only solution. But consesus? Wouldn't dear getting anywhere close to that. :-) Cheers, Ole On 15 Nov 2012, at 16:15, Mikael Abrahamsson swm...@swm.pp.se wrote: On Thu, 15 Nov 2012, Ole Trøan wrote: Or am I missing things again? no, this is pretty much what we imagined, and what Markus has implemented and showed at the IETF. the hosts would still do better if they support rule 5.5 when directly connected to the exits. Absolutely, 5.5 is a plus and gives one less hop in the path, but at least the packet will be ultimately delivered to its final destination. So with the above pretty much what we have imagined, is there consensus that this is the way to go, or this is still being debated? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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
Re: [homenet] DHCP PD for homenets.
On 7 Nov 2012, at 14:50, Teco Boot t...@inf-net.nl wrote: This should be in the homenet-arch, I think. It sounds so obvious to me, that I described this in a short text in BRDP: A Router should request a prefix for attached subnetworks, with DHCP-PD [RFC3633], where there is at that moment no on-link prefix for a selected Border Router. I could make the should a MUST. Disagree. Hierarchical or flat PD (with relays) don't work for multihomed sites, have problems with arbitrary topplogies etc. Cheers, Ole Teco Op 7 nov. 2012, om 16:46 heeft Ted Lemon het volgende geschreven: I don't have a particular preference for DHCP-PD over OSPF in homenets, but I just wanted to quickly contradict what's been said by several people at the mic: that figuring out what prefix to delegate is hard. It's not hard, actually―it's dead easy. The reason folks think it's hard is because they're solving the wrong problem. The problem that needs to be solved is how we number each home subnet. The answer to this question is, with a /64. There is no other answer. You never want to number a subnet with a /52. Therefore, the delegating router should never delegate anything but a /64. Problem solved. I think the disconnect here is that people are thinking the routers to which prefixes are delegated need to themselves be delegating routers, but this is incorrect. What they need to do is _relay_ prefix delegation requests to the delegating router from which they got their own delegation. This scales to multi-homing with multiple delegating routers―you just relay every PD request upstream to all delegating routers. I'd be happy to write a draft that describes how this works if someone actually wants it; I get the sense that people are pretty in love with the OSPF solution and would prefer not to be distracted, and I have no argument with that if that's the working group consensus. ___ 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
Re: [homenet] New Version Notification for draft-howard-homenet-routing-comparison-00.txt
Can you provided a precise definition of walled garden, as well as, define the bi-directional connectivity rules with a few bullets (hopefully less than 5). I fear there may be more than one view of this (or possibly I'm the only one ;^). I presume we are talking about multi-homing to non-congruent topologies. as described here http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03 not sure what exact problems with walled gardens would affect routing though. cheers, Ole Acee == Acee Lindem acee.lin...@ericsson.com writes: The problem with zOSPF is that it doesn't meet our requirements. It doesn't detect borders (unless the border happens to have another zOSPF router with the wrong password), Acee While this should be part of the solution, I don't see this as Acee something that it necessarily should be built into the routing Acee protocol. it requires configuration (for the password), Acee How does any protocol do authentication w/o a shared key? If Acee you don't do authentication, you don't need a key. Yes, this is a general problem, which is why I keep asking what are our real requirements here. it doesn't handle walled gardens (a requirement being debated), Acee I don't fully understand this requirement and how it would be Acee handled w/o configuration. I don't understand this criticism. Why are walled gardens different than multiple ISPs? it's not lightweight. Acee A commercial router implementation supporting all the features Acee including OSPF TE and VPNs is certainly not Acee lightweight. However, I just downloaded the latest quagga Acee suite and it is only about 21K there. rtr3-[/usr/pkg/sbin] mcr 10007 %size ospf6d /usr/pkg/lib/libzebra.so.0 textdata bss dec hex filename 221476 113283132 235936 399a0 ospf6d 272449 238483120 299417 49199 /usr/pkg/lib/libzebra.so.0 No all of libzebra might really be used. So 11K code, plus up to 23K. I think that half of the code can be ripped out (and I wish I had time to do). -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ 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
Re: [homenet] draft-baker-homenet-prefix-assignment
Michael, Is there some reason that the flooding mechanism can't distribute the list of edge CPE routers, and then DHCPv6 can be used in unicast request/reply to ask those CPE routers for things. (I would even wonder if the CPE routers shouldn't be identified by their ULA rather than self-identifying by the address in the subnet the deal with) This is how I imagined the DHCPv6 PD mechanism working before draft-chakrabarti-homenet-prefix-alloc-01 was written, which imagined a strict hierarchal tree. that's how I imagined also. DHCP PD on the edges. flooding protocol between all the internal routers. then hosts use RA/DHCP for addresses / other configurations to their onlink routers. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
Ted, If we do it another way, whether ZOSPF's or some other way, we have the same problem in the sense that there will be multiple sources of subnet prefixes. Yes. This becomes an even uglier problem as you progress into the network, because while at the edge you can tell that you are talking to two administrative domains, as you move into the network past the first delegating router, you wind up with a single DHCP server presenting the merged configuration information from two administrative domains as if they were a single administrative domain. I thought I understood how to solve this problem before I started writing the problem statement, and then when I remembered this aspect of it I kind of flung my hands up in disgust. I think the knowledge that there are two separate administrative domains has to be visible throughout the network, but this is really a substantial divergence from what DHCPv6, at least, currently does. I can certainly imagine extending DHCPv6 in a cascading prefix delegation scenario where it signals this information down the cascade, but it's conceptually quite a bit different. that's exactly reasons why we have started looking at flooding type protocols in homenet as opposed to request/reply protocols. it isn't only multiple sources and service discovery that is problematic with a request/reply protocol, it is also how it handles dynamism. something which was explored in the development of the DNS option for RA. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
We need to be aware that not every network may be able to reach the Internet... So you might need to have an address from every available DHCP server, not just the best, one, or even a random, one. Yes, this is part of a problem space of which I have become keenly aware over the course of this IETF meeting. Expect a draft shortly. :) do we need to? in a self organizing unmanaged home; if we were to do a combination of a network wide flooding mechanism and RAs. would we need DHCP in the network at all? cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
do we need to? in a self organizing unmanaged home; if we were to do a combination of a network wide flooding mechanism and RAs. would we need DHCP in the network at all? I am not claiming that we do. However, the problem exists whether we do DHCP in homenet or not. yes, indeed. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-baker-homenet-prefix-assignment
Fred, We need to be aware that not every network may be able to reach the Internet... So you might need to have an address from every available DHCP server, not just the best, one, or even a random, one. Yes, this is part of a problem space of which I have become keenly aware over the course of this IETF meeting. Expect a draft shortly. :) do we need to? Need to what? Provide a subnet number on each subnet? Is that a real question? extend the DHCP protocol to handle multiple sources of information. cheers, Ole in a self organizing unmanaged home; if we were to do a combination of a network wide flooding mechanism and RAs. would we need DHCP in the network at all? cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] another routing option
Howard, I've said that I don't think we need a full dynamic routing protocol. There are other options for discovering an available path. To stimulate creative thinking, I've written a draft proposing one alternative that should be light to implement in home gateways: http://www.asgard.org/images/draft-howard-up-pio-00.txt If it is interesting, there's more work to be done on it; I could publish it after the pre-meeting publication blackout ends. aren't you in the end just going to reinvent RAs as a distance vector routing protocol...? cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
Erik, btw, border discovery needs to be done regardless of topology or prefix assignment solution choice. on a border you (may) want firewall on, you want a ULA border, you want a organisational or site multicast border... cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
Ted, using the electricity network as an analogy, can we make a distinction between safety and security? the electricity network in the home is somewhat self protecting with breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks and so on. I am highly sympathetic to the desire not to try to solve this problem. However, unfortunately network topology isn't the same as electrical topology, for a couple of reasons. The first reason is that electrical systems are generally set up by professionals. Yes, you plug devices into the electrical wiring of your house, but someone skilled set it up (or if not, I hope you sleep in asbestos pajamas). The devices we are talking about are more analogous to circuit distribution panels than to toasters. The second reason is that electrical systems are essentially topology-free. Any point on the system is essentially equivalent to any other. This is not true of a home network with routing. What we are talking about is essentially the possibility of rogue distribution panels intentionally or accidentally being connected to your distribution system. Which is a result of the third reason: home networks are typically wireless, or partially wireless, and so there is no physical security, unlike an electrical network in a house, which is secure by virtue of being entirely enclosed by the house. I think what you are getting at is that we cannot be responsible for securing the network. And that is probably true. But if the system doesn't have a built-in mechanism for distinguishing between friend and stranger, the autoconfiguration mechanism will create topologies that aren't desired, either by accident or because a stranger wants access to the network. I do agree with that. I think we can figure out a way of pairing devices. whatever layer that ends up being done at. it will be much more difficult to protect against hostiles injecting default routes, or pretending to be DHCP servers and so on. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
Erik, If all the ports are the same, no designated uplink, that is better. While I can see that we can build the internals of the home network with devices without a designated uplink (automatically configure prefixes, the routing protocol etc), what I don't understand is how the connectivity to the ISP would happen. How do you see that working? Will each router try the protocols it would use against the ISP (PPPOE, DHCP PD, etc) on every port? Or on every port where it doesn't find a OSPF (or whatever home routing protocol we choose) neighbor? Or does the user have to configure the Customer Edge Router to say port eth0 is the WAN port? FWIW I haven't seen any discussion to try to automate this. The manual configuration would be just as error prone as making the distinction between the yellow WAN port and the blue LAN ports on current home gear. this is the problem we named border discovery during the interim. there were a few ideas of how that could be done. either implicit or explicit. nothing concluded, and I agree this is an important problem to tackle. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Multilink subnet routing (MLSRv2)
Erik, to expand on the ideas I presented on MLSR (or rather MLSRv2 as it hasn't really been described anywhere) as a method for numbering a routed home. please let me be clear that I'm not convinced this is a good idea. i.e. why not just get /64? I do think we could get something working though. routers can be in an arbitrary topology. all routers running a routing protocol. the site prefix (/64) is either advertised in the IGP with a new LSA or proxying of RA messages is done (split horizon). a router advertises the same /64 prefix (in a PIO) on all of its interfaces. L bit is 0. the link model here is that all hosts are off link from each other. link-local scope is restricted to only the physical link. multicast link-local scope as well. And I assume the routers would pass around /128 routes for the hosts in the home, and would automatically inject such a route when the SAVI-style table learns about a new address. Are those assumptions correct? yes. a host uses SLAAC (or DHCP) to create an address, then does DAD as normal. the first hop router uses it's routing topology database to check for conflicts. similar mechanisms described in SAVI are used to glean address information from the host. the SAVI binding database is then used to inject host routes into the IGP. What happens when the router crashes - does it loose its SAVI-style table? Does it keep it in stable storage? it could. If it looses it, then nobody would know on what link the hosts are, since the hosts aren't required to periodically send any announcement to the routers. indeed. directly connected hosts would get a L2 event. in the more creative department you could run with low timers, and you could enforce a direct mapping between MAC address, link-local address and global address. thereby being able to recreate global address binding state just from a link-local addresses. What happens when a packet arrives for an IP address that is in the /64 prefix for the home, but there is no /128 route for it? Flood everywhere? Drop? drop I'd imagine. We looked that this when we worked on 6lowpan-nd, and concluded that by doing explicit registrations from hosts to routers (the Address Registration Option) with a lifetime we can make such networks work well without requiring stable storage. But that implies a host change. yes, registration makes this safer. I just intended to point out that this could be one tool in the toolbox. not that we should necessarily build homenets this way. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
