Re: [homenet] automatic prefix management (OSPF or ISIS version)
On 22/02/2013 04:50, Fred Baker (fred) wrote: On Feb 22, 2013, at 1:54 PM, Michael Richardson m...@sandelman.ca wrote: For a network where there is more than one ISP, is it acceptable for a CPE that has decided that it is PREFIX1:0123::/64, to randomly decide to be PREFIX2:0123::/64? I don't see why not, at least in the home. There is a case, which homenet hasn't thought much about that I'm aware of, which is renumbering a network. Surely, in a homenet, it's very much the case that (as Fred has hinted over in 6renum) the issue is numbering rather than renumbering. I may be too much of an energy conservation nut for most people, but my homenet is cold-started and numbered most mornings, because it is powered off at bedtime. However, I can see no harm in sticky subnet numbering, as long as the new prefix isn't long enough to overwrite the old subnet numbers. You'll notice in my draft that if the autoconfig prefix is withdrawn, I expect prefixes dependent on it to be withdrawn, and if stored in permanent storage, erased. The implication is that if the same prefix is then readvertised, there's a good chance that all of the subnet numbers will change. I know of at least one scenario where that would be considered a desirable characteristic. But I don't think that case is, at least at this point, a general case or one I would specify beyond a MAY. Actually, do you even need a formal MAY? It's an implementer choice, isn't it? Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
On 22 Feb 2013, at 03:04, David Lamparter equi...@diac24.net wrote: - BIRD seems to be interested in adding IS-IS due to interest from SPs. A branch exists, but not much progress has been made: [https://redmine.labs.nic.cz/projects/bird/repository?utf8=%E2%9C%93rev=isis] Ondrej Filip tells me that this is being worked on again, targeted for release in 2013Q2 Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/2013 03:45, Michael Thomas wrote: ... Well, if one of the requirements is that I be able to control my washing machine from across the continent, Actually we need to be clear about that requirement. There are at least three cases I can imagine: 1. I want to control my washing machine remotely (although I won't be doing that until I have a very reliable dhobi-robot to load and unload it). 2. The manufacturer wants to update my washing machine remotely. 3. A benevolent 3rd party wants to control it remotely. I think you'll find each of these cases has different discovery, naming and security requirements. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
On 21/02/2013 19:23, Fred Baker (fred) wrote: ... http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing Using IS-IS with Role-Based Access Control, Fred Baker, 17-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing IPv6 Source/Destination Routing using IS-IS, Fred Baker, 17-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing Using OSPFv3 with Role-Based Access Control, Fred Baker, 17-Feb-13 http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing IPv6 Source/Destination Routing using OSPFv3, Fred Baker, 17-Feb-13 To get this on the record, I have serious doubts whether the use of the flow label suggested in these drafts is compatible with the current flow label standard (RFC6437). I think this is separable from the general approach, so I'd rather defer discussion until the general approach has been debated. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
I have read all of your drafts, and those of the other authors, carefully, once. No doubt I'll have to re-read them. This response is limited to high level comments regarding the overall approach, and isprobably applicable to all 3 sets of authors : 1. Some drafts talk extensively about the need for an extensible routing protocol, and often mention the desirability of TLV (type-length-value) objects. I agree that a TLV structure potentially solves many issues of how to encode and transport new options between routing protocol speakers. But given that route determination is a distributed algorithm, and that Homenet devices will not always run the latest and greatest code, what action should nodes that are running older code take regarding any TLV options that they don't understand? Isn't there a danger that extensibility will lead to more routing loops, instability, and black holes? Is there a need for all speakers to first agree the (newest) commonly-understood subset of options that all speakers in a Homenet can/will honour before any extension options are transmitted? 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? 3. Limiting this discussion strictly to Homenet requirements: Aren't we forgetting the inter-provider management boundary? My view of the Homenet is a network that is potentially a member of multiple overlapping AS's simultaneously, without being an AS itself. That's highly unusual in routing protocol terms. I think that it is very unlikely that any operator will allow any dynamic routing between a CPE managed by a customer and a PE managed by the provider. I think there's also a potential issue of anyone making any assumptions about dynamic routing being available between a provider-managed CPE and a customer owned CPE. Software version control will not be trivial. The current most likely source of external routing information is DHCPv6-PD, used to locally autoconfigure a floating static default route on the Homenet BR, pointing out of the upstream interface to the Internet. As such, how will any routing information beyond a simple default route (related to a single delegated prefix) be injected into the Homenet? Why are we importing the extra complexity (related to data centres and enterprises) into Homenet? 4. We're still planning on doing something about source address selection, aren't we? For all the suggested complexity of the packet routing solutions suggested so far, isn't the real route selection going to be performed in the host? 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow labels themselves will directly carry any meaning that could be realistically used to make deterministic forwarding decisions by low/mid-powered routers, because you're essentially going to have to reverse a 20 bit hash function to make a forwarding decision? Wouldn't the requirements in rfc6437 also suggest a routing table explosion, because each individual flow would have to be associated with an individual IS-IS route? Perhaps you could distribute some intermediate result to end hosts and routers via IS-IS,which is deterministic and related to policy based routing (such as including the tenant label in a TLV), but which after applying some hash transform and adding some entropy, would comply with the requirements of 6437? That'd potentially reduce the IS-IS routing table size dramatically. I've been waiting 15+ years for fully dynamic PBR and I fully expect to wait some time longer. In any case, with all due respect, I don't think it's relevant for Homenet, 6. Other potentially simpler approaches that might be faster to market I have provided detailed feedback to Ole Lorenzo, suggesting how Homenet could potentially work without modifying any routing protocols at all, with multi-homing, without resorting to NPT, and with BCP38 ingress/egress filters (albeit with a hard link to some yet-to-be-defined autoconfiguration protocol, and a limit that the prefixes of any walled-gardens must be disjoint from other AS's directly connected to this Homenet, and possibly some other limitations such as dumb hosts should not be connected to dual routers from competing providers). Do I need to write a draft on this, or is this already clear? Would someone be willing to help out/ collaborate? If I have other detailed comments on the individual drafts, I'll come back with those. regards, RayH Fred Baker (fred)
Re: [homenet] Egress Routing Discussion: Baker model
On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter v6...@globis.net wrote: But given that route determination is a distributed algorithm, and that Homenet devices will not always run the latest and greatest code, what action should nodes that are running older code take regarding any TLV options that they don't understand? Isn't there a danger that extensibility will lead to more routing loops, instability, and black holes? Yes. If intermediate devices don't understand SADR, you can get routing loops. We should document that clearly and find out how to avoid it. 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. If the right exit is down or gone, then the packet gets dropped, but as the SADR draft explains, you can fix this by telling the homenet routers to deprecate prefixes for which there is no exit. The hosts will then avoid those source addresses for new connections. (The authors of said draft do not agree amongst themselves whether this is the right thing to do or not; but no doubt the WG will have useful opinions here). If you want the hosts to do better load-balancing, then you do need to give them more information. We haven't looked at this. If you want to support walled garden prefixes that do not have complete reachability, then you need to tell the hosts not to use them. I believe DHCPv6 options exist to configure RFC 6724 policy on hosts, but I don't know if anyone supports them, and I haven't thought about the security issues or how to propagate that information through the homenet. 3. Limiting this discussion strictly to Homenet requirements: Aren't we forgetting the inter-provider management boundary? My view of the Homenet is a network that is potentially a member of multiple overlapping AS's simultaneously, without being an AS itself. That's highly unusual in routing protocol terms. I think that it is very unlikely that any operator will allow any dynamic routing between a CPE managed by a customer and a PE managed by the provider. I think there's also a potential issue of anyone making any assumptions about dynamic routing being available between a provider-managed CPE and a customer owned CPE. Software version control will not be trivial. The current most likely source of external routing information is DHCPv6-PD, used to locally autoconfigure a floating static default route on the Homenet BR, pointing out of the upstream interface to the Internet. As such, how will any routing information beyond a simple default route (related to a single delegated prefix) be injected into the Homenet? Why are we importing the extra complexity (related to data centres and enterprises) into Homenet? I thought the idea was that border routers would just do DHCPv6 PD and inject whatever routes they get into the homenet tagged with whatever source prefix they get. They wouldn't participate in any routing protocol with the ISP. We don't currently have any other mechanism for learning external routes, but when we do we can simply treat them in the same way. Does this not work for some reason? 6. Other potentially simpler approaches that might be faster to market I have provided detailed feedback to Ole Lorenzo, suggesting how Homenet could potentially work without modifying any routing protocols at all, with multi-homing, without resorting to NPT, and with BCP38 ingress/egress filters (albeit with a hard link to some yet-to-be-defined autoconfiguration protocol, and a limit that the prefixes of any walled-gardens must be disjoint from other AS's directly connected to this Homenet, and possibly some other limitations such as dumb hosts should not be connected to dual routers from competing providers). Did I miss this? Where can I find it? Was it sent to the list? ___ 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
On Fri, Feb 22, 2013 at 07:17:04PM +0900, Lorenzo Colitti wrote: On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter v6...@globis.net wrote: But given that route determination is a distributed algorithm, and that Homenet devices will not always run the latest and greatest code, what action should nodes that are running older code take regarding any TLV options that they don't understand? Isn't there a danger that extensibility will lead to more routing loops, instability, and black holes? Yes. If intermediate devices don't understand SADR, you can get routing loops. We should document that clearly and find out how to avoid it. [quoting the earler loop sketch for convenience] | 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... [/quote] Since I complained about this earlier, I feel obliged to throw possible approaches around. I'm excluding the prefix-assignment-integrated approach to distributing SADR routing information since that would supposedly by design require all participants to support SADR. For both simple and full-blown OSPFv3 the following loop/interop mechnisms come to my mind: 1. refusing adjacencies between SADR and non-SADR routers. Easily implemented with a Hello bit, this is the crowbar solution. Quite sufficient for homenet I guess, but probably less acceptable for anything else. 2. flagging SADR support in router LSAs/LSPs. Provides enough information to avoid loops. Three things can be done with this information: 2a. install null/reject routes for paths that cross non-SADR routers. Provides adequate failure semantics, instead of looping packets around we get an ICMP unreachable. Easy to implement. Downside: if there really is a non-SADR router, not working is now a state that is part of the result set of the dynamic route calculations. Users (and admins) probably do not expect this. 2b. calculate SPF around non-SADR routers Gets us a working network, but at a cost: there may now be 2 different paths to reach some faraway router, one for SADR-routed packets and a different one for non-SADR packets. Depending on how the router performs its SPF calculations, this can be hard to implement correctly - it's essentially a very narrowly and exactly specified case of multitopology routing. 2c. on encountering non-SADR routers, figure whether they'll do the right thing with the packet. ... complicated and of questionable use IMHO. Just listing this for completeness. 2a and 2b can be mixed with each other; packets will get passed along by 2a-type routers until they get discarded at a 2b-type router. My personal opinion at this point is that 2a and 2b should both be specified, with a requirement to indicate support level in the router documentation. We're unlikely to encounter normal OSPFv3 speakers in a plain production/final homenet, so they could take the easy way. If this gets implemented on routers for enterprise use, I'd expect 2b behaviour. (With the Baker OSPF/ISIS SADR specs quite independent from homenet as they are right now, I think getting homenet-only solutions in those is an unwise idea; homenet optimisation possibilities like allowing fallback to 2a on the other hand should be acceptable.) -David ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On Feb 21, 2013, at 10:45 PM, Michael Thomas m...@mtcc.com wrote: Well, if one of the requirements is that I be able to control my washing machine from across the continent, I'm not sure why we're even screwing with mdns in this wg. And if that's not a requirement for this working group, I have to ask which century it got chartered in. +1 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti lore...@google.com wrote: My point was more that that NPTv6 doesn't make that any easier, more secure, or... anything, really. You still have to update the address somewhere; all that NPTv6 gives you is that now the washing machine doesn't know what its IPv6 address is. Right? I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On Feb 22, 2013, at 7:27 AM, Ted Lemon mel...@fugue.com wrote: Well, if one of the requirements is that I be able to control my washing machine from across the continent, I'm not sure why we're even screwing with mdns in this wg. And if that's not a requirement for this working group, I have to ask which century it got chartered in. +1 Er, that came out wrong. I'm agreeing with want to be able to access devices in the home from away, not working group was chartered in the last century. I am also skeptical about MDNS as a solution, though. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22 Feb 2013, at 03:45, Michael Thomas m...@mtcc.com wrote: Well, if one of the requirements is that I be able to control my washing machine from across the continent, I'm not sure why we're even screwing with mdns in this wg. And if that's not a requirement for this working group, I have to ask which century it got chartered in. It's indirectly mentioned in the charter: While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. ... End-to-end communication is both an opportunity and a concern as it enables new applications ... and it's also explicitly called out in draft-ietf-homenet-arch (§3.7) Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22 Feb 2013, at 12:37, Ted Lemon mel...@fugue.com wrote: Er, that came out wrong. I'm agreeing with want to be able to access devices in the home from away, not working group was chartered in the last century. :) I am also skeptical about MDNS as a solution, though. nohat Personally, I think there's still a good argument to be made for reserving normal unicast DNS for access to globally addressable resources (be that from the home to the outside, or from the outside into the home), whilst using some other protocol for truly internal name resolution. I *really* don't like the idea of each individual Homenet having to create some sort of randomised namespace for its internal DNS. Ray ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
Not sure I buy the security model angle, IPv4 NAT != security. It would be great if we had a group working on service discoveryŠoh wait!? = John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozow...@cable.comcast.com o) 609-377-6594 w) www.comcast6.net = -Original Message- From: Lorenzo Colitti lore...@google.com Date: Thursday, February 21, 2013 5:06 PM To: Dave Taht dave.t...@gmail.com Cc: John Jason Brzozowski john_brzozow...@cable.comcast.com, David Lamparter equi...@diac24.net, Michael Richardson mcr+i...@sandelman.ca, homenet@ietf.org Group homenet@ietf.org, Mark Townsley m...@townsley.net, Jari Arkko jari.ar...@piuha.net Subject: Re: [homenet] Running code in Orlando On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht dave.t...@gmail.com wrote: I still find the dynamicism required by renting ipv6 addresses to so impact in so many aspects of the sane usage of stuff like printers, and naming, and the security model as to *demand* ipv6 nat in the home... Sigh. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
I second the sigh FWIW. And I do not share Dave's view on IPv6 NAT. What are you asking to be demonstrated? IPv6 NAT? = John Jason Brzozowski Comcast Cable m) 484-962-0060 e) john_brzozow...@cable.comcast.com o) 609-377-6594 w) www.comcast6.net = -Original Message- From: Michael Thomas m...@mtcc.com Date: Thursday, February 21, 2013 5:34 PM To: Lorenzo Colitti lore...@google.com Cc: Dave Taht dave.t...@gmail.com, Michael Richardson mcr+i...@sandelman.ca, Mark Townsley m...@townsley.net, Jari Arkko jari.ar...@piuha.net, John Jason Brzozowski john_brzozow...@cable.comcast.com, homenet@ietf.org Group homenet@ietf.org, David Lamparter equi...@diac24.net Subject: Re: [homenet] Running code in Orlando Lorenzo Colitti wrote: On Fri, Feb 22, 2013 at 1:35 AM, Dave Taht dave.t...@gmail.com mailto:dave.t...@gmail.com wrote: I still find the dynamicism required by renting ipv6 addresses to so impact in so many aspects of the sane usage of stuff like printers, and naming, and the security model as to *demand* ipv6 nat in the home... Sigh. Sigh all you like, but I share Dave's skepticism that ISP's renumbering my prefix willy-nilly and it just sort of works with naming -- including addresses squirrelled away in places they ought not be -- is going to work any time soon. I don't like to think that NAT is inevitable but frankly the people in this working group don't get to vote on that. Speaking to the title of this thread: has anybody actually demonstrated such a thing end to end? It strikes me as Frankensteinian when you get all of the body parts bolted together. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 12:30, Ted Lemon wrote: On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti lore...@google.com wrote: I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. The current development release of dnsmasq can act as an authoritative DNS server populated with all hosts on a homenet which it knows about from DHCP. Delegate your domain to it, and ensure that the TTL configured for DNS is smaller than the deprecated lifetime of addresses, and this problem should never arise. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
Lorenzo Colitti mailto:lore...@google.com 22 February 2013 11:17 On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter v6...@globis.net mailto:v6...@globis.net wrote: But given that route determination is a distributed algorithm, and that Homenet devices will not always run the latest and greatest code, what action should nodes that are running older code take regarding any TLV options that they don't understand? Isn't there a danger that extensibility will lead to more routing loops, instability, and black holes? Yes. If intermediate devices don't understand SADR, you can get routing loops. We should document that clearly and find out how to avoid it. ACK. 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. 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? 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. 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. 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? Thus H1 should never send packets with a source address derived from a PIO received in an RA from R2, to a potential default router R1 that sent an RA
Re: [homenet] Running code in Orlando
Actually they do. They have the freedom to specify alternatives, and depending on how good a job they do, implementers may choose to use them. Šand providing that these are specified by people who know what they doing and understand the problem that is being solved/addressed. :O ___ 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] NPTv6-only home networks
On Fri, Feb 22, 2013 at 01:00:48PM +, Simon Kelley wrote: On 22/02/13 12:30, Ted Lemon wrote: On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti lore...@google.com wrote: I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. The current development release of dnsmasq can act as an authoritative DNS server populated with all hosts on a homenet which it knows about from DHCP. Delegate your domain to it, and ensure that the TTL configured for DNS is smaller than the deprecated lifetime of addresses, and this problem should never arise. This only works with stateful DHCPv6 though? -David ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
-Original Message- From: Michael Thomas m...@mtcc.com Date: Thursday, February 21, 2013 5:57 PM To: Lorenzo Colitti lore...@google.com Cc: Dave Taht dave.t...@gmail.com, Michael Richardson mcr+i...@sandelman.ca, Mark Townsley m...@townsley.net, Jari Arkko jari.ar...@piuha.net, John Jason Brzozowski john_brzozow...@cable.comcast.com, homenet@ietf.org Group homenet@ietf.org, David Lamparter equi...@diac24.net Subject: Re: [homenet] Running code in Orlando Lorenzo Colitti wrote: On Fri, Feb 22, 2013 at 10:34 AM, Michael Thomas m...@mtcc.com mailto:m...@mtcc.com wrote: Sigh. Sigh all you like, but I share Dave's skepticism that ISP's renumbering my prefix willy-nilly and it just sort of works with naming -- including addresses squirrelled away in places they ought not be -- is going to work any time soon. That's why we have ULAs and multiple prefixes. ULA's are of limited use. I still want to start my washing machine regardless of whether I'm at home or not. [jjmb] maybe today, who knows about tomorrow. I don't like to think that NAT is inevitable but frankly the people in this working group don't get to vote on that. Actually they do. They have the freedom to specify alternatives, and depending on how good a job they do, implementers may choose to use them. Wishful thinking. NAT's didn't start with the blessing of IETF as I recall. They just happened. If the alternatives are too whacked out, history will repeat itself. [jjmb] not sure I agree here, the conditions and parameters are different today specifically there are currently no issues with IPv6 resource availability. Speaking to the title of this thread: has anybody actually demonstrated such a thing end to end? It strikes me as Frankensteinian when you get all of the body parts bolted together. What thing exactly? Multiprefix multihoming? End-to-end connectivity in general? Yes, along with naming, security, prefix delegation across multiple routers, and isp's giving and withdrawing prefixes due to renumbering. I'm dubious that this has happened in real life with networks with people whose day job is to worry about such things, and I'd be astonished to hear such a thing has been shown to work on a home network. [jjmb] hmmm we have quite a few real customers that are using IPv6 enabled on a daily basis mostly using technology that we specified ~8 years ago. Does this count? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 13:07, David Lamparter wrote: On Fri, Feb 22, 2013 at 01:00:48PM +, Simon Kelley wrote: On 22/02/13 12:30, Ted Lemon wrote: On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti lore...@google.com wrote: I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. The current development release of dnsmasq can act as an authoritative DNS server populated with all hosts on a homenet which it knows about from DHCP. Delegate your domain to it, and ensure that the TTL configured for DNS is smaller than the deprecated lifetime of addresses, and this problem should never arise. This only works with stateful DHCPv6 though? It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers an awful lot of currently-deployed clients. The IPv4 addresses can be RFC1918, the DHCPv4 lease is used to give dnsmasq the MAC address and name of a client. The authoritative DNS module is configurable to expose global IPv6 addresses and hide RFC1918 IPv4 addresses. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
fred == fred Baker (fred) f...@cisco.com writes: fred my draft that if the autoconfig prefix is withdrawn, I expect fred prefixes dependent on it to be withdrawn, and if stored in fred permanent storage, erased. The implication is that if the same fred prefix is then readvertised, there's a good chance that all of fred the subnet numbers will change. I know of at least one fred scenario where that would be considered a desirable fred characteristic. But I don't think that case is, at least at fred this point, a general case or one I would specify beyond a fred MAY. Assuming that the random seed is not erased, or that another prefix has been announced before the original withdrawn, then the seed might persist. (Remember that ULA prefix...) Can you elaborate the scenario where a subnet-id renumbering would be desireable, and would we want to actually signal this situation explicitely? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ pgpnQfnIbDS8P.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
On Feb 21, 2013, at 8:34 PM, Michael Thomas m...@mtcc.com wrote: Sigh all you like, but I share Dave's skepticism that ISP's renumbering my prefix willy-nilly and it just sort of works with naming -- including addresses squirrelled away in places they ought not be -- is going to work any time soon. I don't like to think that NAT is inevitable but frankly the people in this working group don't get to vote on that. It's probably also worth mentioning that in general ISPs that do this on a regular basis are attacking their customer's network, and the resulting instability is not the result of a failing on our part, but deliberate action on the part of the ISP. There are countries where ISPs are required by law to _offer_ a change of address every 24 hours for privacy purposes. At least in the cases I'm aware of, ISPs don't _force_ this on their customers, but rather it's a configuration option paranoid customers can choose, which may default to on.This is an inconvenience to ISPs, because it causes address pool churn, and requires a lot of extra bits to be allocated to PE devices to accommodate all the deprecated addresses. Pretty much by definition, if you want to access your washing machine while away from home, you're throwing that particular sort of privacy right out the window. It wasn't buying you much anyway--fuzzing the prefix by a few bits is very easy to reverse, and because of routing hierarchies, IPv6 prefixes can't be assigned to the customer out of the ISP's entire address space--by definition they will be restricted to localities. The other use case for frequent renumbering is an ISP who wants to prevent the customer from setting up servers. The washing machine is a server. Either the ISP succeeds, or fails, but in either case, they are acting directly against the customer's wishes.We can try to design a system that's robust with respect to attacks like this, but in practice the best way to address this problem is to prevent it happening on a regular basis to people who will care about it. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On Feb 22, 2013, at 7:49 AM, Ray Bellis ray.bel...@nominet.org.uk wrote: I *really* don't like the idea of each individual Homenet having to create some sort of randomised namespace for its internal DNS. I don't either, but that's not the only way to approach the problem. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On Feb 22, 2013, at 8:24 AM, Simon Kelley si...@thekelleys.org.uk wrote: It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers an awful lot of currently-deployed clients. So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
Small add-on to the address-renew policy @ some ISPs Some ISPs do refresh the IP every XX hours for several reasons: * privacy * different contracts, i.e. you pay more for fixed IP over dynamic IP, i.e. allows hosting on same IP The same will be applied for IPv6. Best regards Carl Wuyts Help preserve the color of our world - Think before you print. -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Ted Lemon Sent: vrijdag 22 februari 2013 15:48 To: Michael Thomas Cc: Michael Richardson; Mark Townsley; Dave Taht; Jari Arkko; Brzozowski, John; homenet@ietf.org Group; David Lamparter; Lorenzo Colitti Subject: Re: [homenet] Running code in Orlando On Feb 21, 2013, at 8:34 PM, Michael Thomas m...@mtcc.com wrote: Sigh all you like, but I share Dave's skepticism that ISP's renumbering my prefix willy-nilly and it just sort of works with naming -- including addresses squirrelled away in places they ought not be -- is going to work any time soon. I don't like to think that NAT is inevitable but frankly the people in this working group don't get to vote on that. It's probably also worth mentioning that in general ISPs that do this on a regular basis are attacking their customer's network, and the resulting instability is not the result of a failing on our part, but deliberate action on the part of the ISP. There are countries where ISPs are required by law to _offer_ a change of address every 24 hours for privacy purposes. At least in the cases I'm aware of, ISPs don't _force_ this on their customers, but rather it's a configuration option paranoid customers can choose, which may default to on.This is an inconvenience to ISPs, because it causes address pool churn, and requires a lot of extra bits to be allocated to PE devices to accommodate all the deprecated addresses. Pretty much by definition, if you want to access your washing machine while away from home, you're throwing that particular sort of privacy right out the window. It wasn't buying you much anyway--fuzzing the prefix by a few bits is very easy to reverse, and because of routing hierarchies, IPv6 prefixes can't be assigned to the customer out of the ISP's entire address space--by definition they will be restricted to localities. The other use case for frequent renumbering is an ISP who wants to prevent the customer from setting up servers. The washing machine is a server. Either the ISP succeeds, or fails, but in either case, they are acting directly against the customer's wishes.We can try to design a system that's robust with respect to attacks like this, but in practice the best way to address this problem is to prevent it happening on a regular basis to people who will care about it. ___ 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] NPTv6-only home networks
Ted Lemon wrote: On Feb 21, 2013, at 11:31 PM, Lorenzo Colitti lore...@google.com wrote: My point was more that that NPTv6 doesn't make that any easier, more secure, or... anything, really. You still have to update the address somewhere; all that NPTv6 gives you is that now the washing machine doesn't know what its IPv6 address is. Right? I think the issue that Michael imagines NPTv6 will address is the transition period, when the washing machine has two IP addresses, and the DNS may not have the new address, or may have both addresses, and he's hoping the gateway will somehow bandage this up. However, the gateway's ability to bandage this up is more imagined than real, and we might as well just fix the underlying problem. Just to be perfectly clear, I'm not imagining NPTv6 working at all. (and how did this get turned into npt vs nat?) My fear is that the complexity of all of this will drive people and manufacturers to simple and brain dead solutions that do not meet the requirement that I be able to control my washing machine across the continent, for example. Renumbering is something that has gotten a lot of attention over the years in ietf, but its intersection with naming is still problematic as far as I can tell in the real world, and is likely to be even more problematic in with low-clue home networks. Right now, I don't think that sufficient energy is being given to just one obvious problem: how does real DNS interact with prefix delegation in the home (assuming that we don't want split horizon dns)? For that matter, let me be even more blunt: I don't think that real DNS is being given enough attention altogether in home settings, and until that happens we'll just inherit all of the awful hacks that are done with NATv4. Mike ___ 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
I went through the draft, and noticed an instance of the word hoemnet in section 2.4. Otherwise I think this is now in good shape for publication. Regards Brian On 12/02/2013 15:00, Ray Bellis wrote: This email marks the commencement of Working Group Last Call for draft-ietf-homenet-arch-07. The WGLC will end on Monday March 4th. Ray and Mark. ___ 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] Egress Routing Discussion: Baker model
From: Lorenzo Colitti lore...@google.commailto:lore...@google.com Date: Thursday, February 21, 2013 5:41 PM To: Fred Baker f...@cisco.commailto:f...@cisco.com Cc: homenet@ietf.orgmailto:homenet@ietf.org Group homenet@ietf.orgmailto:homenet@ietf.org, Abhay Roy (akr) a...@cisco.commailto:a...@cisco.com, isis-cha...@tools.ietf.orgmailto:isis-cha...@tools.ietf.org isis-cha...@tools.ietf.orgmailto:isis-cha...@tools.ietf.org, ospf-cha...@tools.ietf.orgmailto:ospf-cha...@tools.ietf.org ospf-cha...@tools.ietf.orgmailto:ospf-cha...@tools.ietf.org Subject: Re: [homenet] Egress Routing Discussion: Baker model Extending the routing protocols will be a long and possibly hard road, and we feel that the group should at least consider the possibility of an approach with better time-to-market and lower barrier to implementation - especially since the alternatives being proposed are hierarchical DHCPv6 PD and NPT66. The risk is that we make the perfect the enemy of the good and we end up with NPT66, [CD] There's another alternative we've added to eRouter (see draft-grundemann-homenet-hipnet) - hierarchical DHCPv6 without NPT66. For multihoming, you can do source/dest routing at the CER(s), if necessary, not every router. No routing protocol required, and no v6 NAT. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
Ted Lemon wrote: On Feb 21, 2013, at 8:34 PM, Michael Thomas m...@mtcc.com wrote: Sigh all you like, but I share Dave's skepticism that ISP's renumbering my prefix willy-nilly and it just sort of works with naming -- including addresses squirrelled away in places they ought not be -- is going to work any time soon. I don't like to think that NAT is inevitable but frankly the people in this working group don't get to vote on that. It's probably also worth mentioning that in general ISPs that do this on a regular basis are attacking their customer's network, and the resulting instability is not the result of a failing on our part, but deliberate action on the part of the ISP. There are countries where ISPs are required by law to _offer_ a change of address every 24 hours for privacy purposes. At least in the cases I'm aware of, ISPs don't _force_ this on their customers, but rather it's a configuration option paranoid customers can choose, which may default to on.This is an inconvenience to ISPs, because it causes address pool churn, and requires a lot of extra bits to be allocated to PE devices to accommodate all the deprecated addresses. Pretty much by definition, if you want to access your washing machine while away from home, you're throwing that particular sort of privacy right out the window. It wasn't buying you much anyway--fuzzing the prefix by a few bits is very easy to reverse, and because of routing hierarchies, IPv6 prefixes can't be assigned to the customer out of the ISP's entire address space--by definition they will be restricted to localities. The other use case for frequent renumbering is an ISP who wants to prevent the customer from setting up servers. The washing machine is a server. Either the ISP succeeds, or fails, but in either case, they are acting directly against the customer's wishes.We can try to design a system that's robust with respect to attacks like this, but in practice the best way to address this problem is to prevent it happening on a regular basis to people who will care about it. Is there any way to convince the powers that be that v6 address privacy is a better/acceptable solution than prefix-based privacy? Is there really anything that needs to be done for v6 on that account other than just switching on the, oh say, laptop? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
Brzozowski, John wrote: general? Yes, along with naming, security, prefix delegation across multiple routers, and isp's giving and withdrawing prefixes due to renumbering. I'm dubious that this has happened in real life with networks with people whose day job is to worry about such things, and I'd be astonished to hear such a thing has been shown to work on a home network. [jjmb] hmmm we have quite a few real customers that are using IPv6 enabled on a daily basis mostly using technology that we specified ~8 years ago. Does this count? Not really because my understanding is that these networks are giving a service that is pretty much the same as their v4 counterpart which is completely client centric. I seriously want globally accessible servers on my home network to be 1st class citizens and that implies naming and security/admission control. The future is now: a Raspberry Pi is $35. Tomorrow, we'll be getting gratuitous IP-enabled controllers on everything whether we want them or not just like when digital controls replaced analog. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 2/22/13 7:24 AM, Michael Thomas wrote: joel jaeggli wrote: On 2/21/13 7:04 PM, Michael Thomas wrote: So, I think what we can observe from the number of readily discoverable security cameras on the internet. was that the real-live requirement was at least partially solved thanks to upnp and dynamic dns registration, is not a geek-only-oddity, survives renumbering, and was for the most part done quite badly. hopefully it can be done better in the future. I was under the impression that upnp is exactly what we should not be aspiring to, but that we'll get by default (like natv6) if nothing useful happens in ietf. my point was not that upnp was worth aspiring too. it was that the existence proof for servers in the home is all over the place even in the the state of brokenness. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 14:50, Ted Lemon wrote: On Feb 22, 2013, at 8:24 AM, Simon Kelley si...@thekelleys.org.uk wrote: It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers an awful lot of currently-deployed clients. So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration? As the DHCPv4 state machine moves to lease complete it spits a (MAC address, hostname, broadcast domain) tuple over to the IPv6 side. The broadcast domain plus configuration yields a list of prefixes, and the MAC address gets turned into a SLAAC host-identifier. The two make a set of putative addresses. The state machine then sends an ICMP6 echo request to each putative address and if it responds then that address is added as an record with the hostname. There are some implementation details involving timeouts and retries and sending speculative router advertisements to ensure that a new-on-the-network host is ready to reply to the pings. The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 23, 2013, at 3:16 AM, Michael Richardson mcr+i...@sandelman.ca wrote: Lorenzo == Lorenzo Colitti lore...@google.com writes: I.e. the 0123 is identical for the two prefixes? Lorenzo In the general case where the prefixes assigned by the Lorenzo operators are of different lengths, it cannot be. Right? True. If the ISP with the longest prefix is alive first, then the routers pick subnet-id parts that fit into that. If that ISP has provided enough subnets, then even when another ISP comes along, the xx23 part might remain stable for a long time. I think this is a human friendly feature that none of our protocols should depend upon, but that nothing should forbid. Do you agree? -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works I think we have violent agreement here. The text we're discussing is section anchor=allocation title=Subnet prefix allocation and announcement tEach router advertising a xref target=RFC5308Reachability TLV /xref, including a pseudonode on a LAN, when it receives the Autoconfiguration TLV Advertisement, calculates and announces a more specific prefix from the advertised autoconfiguration prefix in a Reachability TLV. This prefix is chosen at random, but may not collide with any prefix currently advertised within the network and therefore in the LSP database./t If you would like I can change This prefix is chosen at random, but may not collide with any prefix currently advertised within the network and therefore in the LSP database. to read In the absence of other considerations, this prefix is chosen at random. It MAY be derived from previous prefix allocation decisions, such as a prefix stored in nonvolatile memory, the prefix used by a previous pseudonode on the same LAN, or the subnet part of another prefix on the same interface. In any event, it MUST NOT collide with any prefix currently advertised within the network and therefore in the LSP database. BTW, a side-note on the issue of non-volatile memory. The OSPF autoconfig draft says that an allocated prefix MUST be stored in non-volatile memory and as a result survive a reboot. Speaking for myself, I don't see the need for that; I'm not opposed to someone doing it, but they now have to think about what happens when for various kinds of network changes. I think the principle might be one of least surprise; if a certain prefix is in use on a LAN and the DIS changes (perhaps the old one fails), the new DIS should use the same prefix as the old one, so that the hosts don't have to jump through hoops. That said, I don't see the argument around a whole-building power failure; unless there is a server being advertised in DNS, a randomly-selected new prefix will work just as well as the old one. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
fred == fred Baker (fred) f...@cisco.com writes: fred If you would like I can change fred This prefix is chosen at random, but may not collide with any fred prefix currently advertised within the network and therefore fred in the LSP database. fred to read fred In the absence of other considerations, this prefix is chosen fred at random. It MAY be derived from previous prefix allocation fred decisions, such as a prefix stored in nonvolatile memory, the fred prefix used by a previous pseudonode on the same LAN, or the fred subnet part of another prefix on the same interface. In any fred event, it MUST NOT collide with any prefix currently fred advertised within the network and therefore in the LSP fred database. I like. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works pgpfnt1ntXk4o.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 23, 2013, at 3:18 AM, Michael Richardson mcr+i...@sandelman.ca wrote: Can you elaborate the scenario where a subnet-id renumbering would be desireable, and would we want to actually signal this situation explicitly? There is a BAA (a request for a research proposal) from the US Air Force for a technology or methodology that would enable a network to morph under attack. A presumably-related question came to me a couple of years ago from a researcher at Johns Hopkins APL; she wondered whether it would be possible for a network to blunt a DDOS attack without betraying the information that the attack had been detected. One way that *could* work would be to have the network periodically renumber. Imagine the network as a whole, or individual LANs from time to time, adding a prefix, making the old one not preferred, and then removing the old one a few minutes later. The network endures the attack for a little while and then - not because it has detected an attack, but because it would do so anyway - side-steps it in routing. I'm imagining the operators in the room giggling to themselves at this point, or tearing their hair before running screaming from the room. One would not want to have to debug anything in such a network. But that's what I'm referring to. I can imagine a network that, by policy, actively wants the algorithm to choose a new number. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
inline On Feb 23, 2013, at 12:48 AM, David Lamparter equi...@diac24.net wrote: For both simple and full-blown OSPFv3 the following loop/interop mechnisms come to my mind: 1. refusing adjacencies between SADR and non-SADR routers. Easily implemented with a Hello bit, this is the crowbar solution. Quite sufficient for homenet I guess, but probably less acceptable for anything else. 2. flagging SADR support in router LSAs/LSPs. Provides enough information to avoid loops. Three things can be done with this information: 2a. install null/reject routes for paths that cross non-SADR routers. Provides adequate failure semantics, instead of looping packets around we get an ICMP unreachable. Easy to implement. Downside: if there really is a non-SADR router, not working is now a state that is part of the result set of the dynamic route calculations. Users (and admins) probably do not expect this. 2b. calculate SPF around non-SADR routers Gets us a working network, but at a cost: there may now be 2 different paths to reach some faraway router, one for SADR-routed packets and a different one for non-SADR packets. Depending on how the router performs its SPF calculations, this can be hard to implement correctly - it's essentially a very narrowly and exactly specified case of multitopology routing. 2c. on encountering non-SADR routers, figure whether they'll do the right thing with the packet. ... complicated and of questionable use IMHO. Just listing this for completeness. 2a and 2b can be mixed with each other; packets will get passed along by 2a-type routers until they get discarded at a 2b-type router. My personal opinion at this point is that 2a and 2b should both be specified, with a requirement to indicate support level in the router documentation. We're unlikely to encounter normal OSPFv3 speakers in a plain production/final homenet, so they could take the easy way. If this gets implemented on routers for enterprise use, I'd expect 2b behaviour. So you want the non-SADR routers to implement a null route, and the SADR routers to route around the non-SADR routers. I'm scratching my head on how the un-updated routers would know to install a null route if they don't understand the information. I do think it would be straightforward to add a flag to the Hello indicating that they understand such updates, and refusing to neighbor with a router that doesn't. We have done that for other features. That does mean that adding a router to an area that understands the updates forces an update to all of the routers in an area, which could be a pain when upgrading. Setting a flag in the Router LSA indicating willingness to handle these routes is possible, but takes us in the direction of topological routing. My problem with approaching it as a topology is the implied management overhead; we need to know whether to include any given router or link in a given topology, and where we might have advertised topology-specific metrics in RFC 4915, we now want to infer that from a capability flag. ick. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On Feb 22, 2013, at 10:01 AM, Michael Thomas m...@mtcc.com wrote: Right now, I don't think that sufficient energy is being given to just one obvious problem: how does real DNS interact with prefix delegation in the home (assuming that we don't want split horizon dns)? For that matter, let me be even more blunt: I don't think that real DNS is being given enough attention altogether in home settings, and until that happens we'll just inherit all of the awful hacks that are done with NATv4. Agreed. I'm delighted to hear that Simon has a hack in dnamasq that addresses this problem in a dual-stack environment, but I want to have a serious conversation somewhere about how to address the problem on the v6-only homenet. Who's interested in sketching a DNS-based solution to the problem and has time to work on it? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Running code in Orlando
On Feb 22, 2013, at 10:37 AM, Michael Thomas m...@mtcc.com wrote: Is there any way to convince the powers that be that v6 address privacy is a better/acceptable solution than prefix-based privacy? Is there really anything that needs to be done for v6 on that account other than just switching on the, oh say, laptop? I don't think address-based privacy offers any privacy at all, since the tracker can just track the prefix. The problem is that this is also true of the customer prefix. I think the idea that you can get privacy by changing the IP address or prefix is hopelessly naive. If you want privacy, you probably need something like TOR, only commercial, but even then what you get is privacy from everybody but your TOR provider. Ironically, the simplest version of this commercial TOR for IPv6 is an NPTv6 router somewhere near the backbone. :} ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On Feb 22, 2013, at 10:53 AM, Simon Kelley si...@thekelleys.org.uk wrote: The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. That is _very_ cool. Nice work! ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NPTv6-only home networks
On 22/02/13 19:48, Ted Lemon wrote: On Feb 22, 2013, at 10:53 AM, Simon Kelley si...@thekelleys.org.uk wrote: The practice is that it always works, even a smartphone moving slowly into a dodgy Wifi network. If the client can get a DHPCv4 lease, the IPv6 SLAAC address gets a name too. That is _very_ cool. Nice work! I make no claims for the invention, only the implementation. I'm aware of it being independently invented at least twice, involving at least three different people. Simon. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 22, 2013, at 06:16 , Michael Richardson mcr+i...@sandelman.ca wrote: If the ISP with the longest prefix is alive first, then the routers pick subnet-id parts that fit into that. If that ISP has provided enough subnets, then even when another ISP comes along, the xx23 part might remain stable for a long time. This problem is precisely why I campaigned bitterly and vigorously against the adoption and V6OPS and later the publication of RFC 6177. When there was still a consensus that subscribers should always get a /48 prefix, it was reasonable to expect that a randomly chosen 16-bit subnet identifier would be unlikely to collide with another subnet in most automatically numbered routing domains. We were also in a position to expect that when a subscriber adds a new prefix from the same or a different provider, that all the subnet identifiers in use on one prefix could be mapped 1:1 into the new prefix. Now we have RFC 6177, which explodes all of that, for basically no sensible reason that I can see, and we are all the poorer for it. Well done, V6OPS, well done. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
also inline On Fri, Feb 22, 2013 at 05:41:43PM +, Fred Baker (fred) wrote: inline On Feb 23, 2013, at 12:48 AM, David Lamparter equi...@diac24.net wrote: For both simple and full-blown OSPFv3 the following loop/interop mechnisms come to my mind: 1. refusing adjacencies between SADR and non-SADR routers. Easily implemented with a Hello bit, this is the crowbar solution. Quite sufficient for homenet I guess, but probably less acceptable for anything else. 2. flagging SADR support in router LSAs/LSPs. Provides enough information to avoid loops. Three things can be done with this information: 2a. install null/reject routes for paths that cross non-SADR routers. Provides adequate failure semantics, instead of looping packets around we get an ICMP unreachable. Easy to implement. Downside: if there really is a non-SADR router, not working is now a state that is part of the result set of the dynamic route calculations. Users (and admins) probably do not expect this. 2b. calculate SPF around non-SADR routers Gets us a working network, but at a cost: there may now be 2 different paths to reach some faraway router, one for SADR-routed packets and a different one for non-SADR packets. Depending on how the router performs its SPF calculations, this can be hard to implement correctly - it's essentially a very narrowly and exactly specified case of multitopology routing. 2c. on encountering non-SADR routers, figure whether they'll do the right thing with the packet. ... complicated and of questionable use IMHO. Just listing this for completeness. 2a and 2b can be mixed with each other; packets will get passed along by 2a-type routers until they get discarded at a 2b-type router. My personal opinion at this point is that 2a and 2b should both be specified, with a requirement to indicate support level in the router documentation. We're unlikely to encounter normal OSPFv3 speakers in a plain production/final homenet, so they could take the easy way. If this gets implemented on routers for enterprise use, I'd expect 2b behaviour. So you want the non-SADR routers to implement a null route, and the SADR routers to route around the non-SADR routers. No - sorry for not wording this clearly enough. I want SADR routers to notice that they've hit a non-SADR router in their SPF calculation. And if they do, the SADR routers can either install a null route (and keep topological sanity, flagging the route under consideration down as sorry no can do), or go the alternate topology way. I'm scratching my head on how the un-updated routers would know to install a null route if they don't understand the information. They don't, indeed. I do think it would be straightforward to add a flag to the Hello indicating that they understand such updates, and refusing to neighbor with a router that doesn't. We have done that for other features. That does mean that adding a router to an area that understands the updates forces an update to all of the routers in an area, which could be a pain when upgrading. I think moving this flag to the router LSA is under all circumstances preferable over this. With the null route variant, it gives a painless upgrading path that keeps plain-old destination routing working; SADR can then be put into use when the relevant routers have the support. Setting a flag in the Router LSA indicating willingness to handle these routes is possible, but takes us in the direction of topological routing. My problem with approaching it as a topology is the implied management overhead; we need to know whether to include any given router or link in a given topology, and where we might have advertised topology-specific metrics in RFC 4915, we now want to infer that from a capability flag. ick. This is exactly why the SADR routers can instead go install a null route, the only thing needed there is checking whether any router on the calculated path doesn't support SADR. FWIW, I think the double topology idea is not completely out of whack, though admittedly complicated and complex. The semantics are reasonably well-defined, it boils down to bifurcating into exactly two topologies, one normal and one SADR. I'm not particularly keen or tacked down on it though. -David P.S.: I can write this up in spec form if desired, I'm relatively new to IETF and have no idea how this works and all. Shall I put some text together for the null route variant and throw it in here? That would as a side effect make it easier to evaluate the idea, I think. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Egress Routing Discussion: Baker model
On Fri, 22 Feb 2013, Ole Troan wrote: 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 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). But CE1 and CE2 share an interface in this case (the LAN). Shouldn't they be able to observe each others RA packets and from them discern what source addresses should go where? If CE1 receives packets from sources that is not from any address that CE1 has sent out RAs or DHCPv6-PD subdelegated from, then it's pretty obvious that these packets should not go out its default route because they're going to get dropped by ISP1 uRPF anyway. If it sees another router advertising those addresses on the LAN (or actually any addresses in case there are only two routers), then it should send the packets there. I know this doesn't solve other topologies, but in this perticular case it should be doable (but requires new functionality in the routers, but the hosts do not need any new functionality). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
