Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 26, 2013, at 1:01 AM, Cameron Byrne cb.li...@gmail.com wrote: Ok. I see it in the charter. I dont find it particularly appealing or worth a great trade off for the level of complexity involved. Especially if the tradeoffs require nat66 or something similarly complex Touché. Seriously, though, the point of routing in the home is that you really don't want to bridge disparate media, and you want routers plugged together by people who don't know about routing to create a happy, functioning network, not a dysfunctional network that sort of works but is never satisfactory. I'm sure Mark would give you a different sales pitch, but that's why I'm interested in it. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 25, 2013, at 19:35 , Lorenzo Colitti lore...@google.com wrote: However, the moment you try to use more /64s internally than you have externally, stateless NPTv6 doesn't work any more, right? Correct. But remember: I *never* write NAT66 when what I mean is NPTv6. I really did mean NAT66 and not NPTv6. In this scenario, we would number HOMENET domains with 16 bits of ULA subnet identifier and 64 bits of interface identifier for hosts on each subnet. Then we would NAT66 the ULA /48 prefix into whatever addresses are in the pool of longer prefixes the service provider gives us because they won't give us a /48 at an acceptable price. We would not use NPTv6, as that doesn't work. We would then use the PCP protocol to control NAT66 mappings just the same as we do today with NAT44 mappings, but the good news is that PCP explicitly supports that form of IPv6/NAT so it's all good. Thank you PCP working group. Yes, this breaks referral in IPv6 even more than it's already broken, but I'm thinking service providers will be happy with that overall. If I were building an IPv6 home gateway to support routed home networks today, this is how I would feel compelled to do it. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
Sent from ipv6-only Android On Feb 26, 2013 8:19 PM, Ole Troan o...@cisco.com wrote: Ok. I see it in the charter. I dont find it particularly appealing or worth a great trade off for the level of complexity involved. Especially if the tradeoffs require nat66 or something similarly complex Touché. Seriously, though, the point of routing in the home is that you really don't want to bridge disparate media, and you want routers plugged together by people who don't know about routing to create a happy, functioning network, not a dysfunctional network that sort of works but is never satisfactory. exactly. the arguments I've heard are: - people just plug in whatever they bought, it must work regardless of being a router or a bridge How does routing make this better for a homenet ? Ethernet supports arbitrary topologies. - not all link-layers can be bridged together e.g. 802.15.4 Whos requirement is that? Is it a primary use case or can be a stub L3 link - problems with bridging links with very different speed characteristics e.g. 802.11 and 1G wired Routing is better? - isolation between networks with different policy, e.g. guest networks, internal home automation, public wifi Seems like homenet is trying to devine the special sauce that makes Frankenstein come alive. Warning ... my home network includes exactly 1 802.11g AP that cost $50 6 years ago and effectively is Zero configuration. CB cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
james == james woodyatt j...@apple.com writes: james Correct. But remember: I *never* write NAT66 when what I mean james is NPTv6. I really did mean NAT66 and not NPTv6. james In this scenario, we would number HOMENET domains with 16 james bits of ULA subnet identifier and 64 bits of interface james identifier for hosts on each subnet. Then we would NAT66 the james ULA /48 prefix into whatever addresses are in the pool of james longer prefixes the service provider gives us because they james won't give us a /48 at an acceptable price. We would not use james NPTv6, as that doesn't work. If we must assume that the ISPs will be dorks, then I'd rather just stick to triple-NAT'ed IPv4, and then the clueful people will get a tunnel to sixxs or some place clueful. I seem to recall that this is what we did with the ISDN, X.25 and the rest of the incumbent carrier controlled protocols we had in the 1980s: we used them as pipes for something decent. -- ] 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[ pgpQZgs6fp4uy.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 14:24 , Fred Baker (fred) f...@cisco.com wrote: One: the v6ops result reflects the operational result in the ARIN community: operators there would like to be able to allocate /56 prefixes to smaller customers and /48s to larger ones. If you want castigate someone, castigate them. I'm unable to participate in ARIN or other RIR discussions, otherwise they would have heard a bellyful from me about it. I'd castigate *them* here too, but that would be off topic. Two: If randomization within the home is the issue, I'm not sure the difference between a /48 and a /56 is all that significant. The point I wished to make is that we don't have a reasonable expectation that the size of a HOMENET subnet identifier will ever be constant over time and across renumbering events, much less across transfers between providers. We're not even confident that a HOMENET will even be offered *any* space for a subnet identifier. As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them. Any HOMENET autoprefix system will depend on the proper configuration of a central subnet identifier registry integrated or tightly coupled with the border gateway. When new link routers arrive, they have to ask the central registry for the next available subnet identifier and take out a lease on it, just like an IPv4 host that has to maintain a lease to use its interface addresses with DHCP. When link routers leave, they have to release their lease or the network must wait for it to timeout. And what happens when a HOMENET has four link routers in it, and the ISP renumbers the delegated prefix from a /60 to a /63? Obviously, something in the network has to kick two of the routers out of the HOMENET, but which two? Does the subscriber even get to choose? Basically, we've given up on stateless router autoconfiguration in HOMENET, and we're forced into a stateful solution. There are no good choices here, and the worst case outcome is that we will force the widespread adoption of NAT66 at HOMNET borders, precisely because it may turn out that subscribers want stable subnet identifiers, and more of them than their service providers are willing to provide at reasonable price. This all happened before, and we're not showing any signs of making sure it doesn't happen again. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 25, 2013, at 11:21 AM, james woodyatt j...@apple.com wrote: Basically, we've given up on stateless router autoconfiguration in HOMENET, and we're forced into a stateful solution. There are no good choices here, and the worst case outcome is that we will force the widespread adoption of NAT66 at HOMNET borders, precisely because it may turn out that subscribers want stable subnet identifiers, and more of them than their service providers are willing to provide at reasonable price. This all happened before, and we're not showing any signs of making sure it doesn't happen again. Here I'm a little confused. Who is we? To my knowledge, homenet hasn't given up on automated subnet allocation. If homenet has, no problem, let the draft expire. If the ISP wants to allocate specific /64s to a customer, that's actually OK. It requires some thought, however. We are going to have to send a DHCP-PD request from each router in the network to the ISP's DHCP-PD server, which will allocate some number of /64s to the requesting router. I don't know about your world; in my world, it's not unusual for routers to have more than two interfaces; in a home using wireless and wifi, one could imagine each router asking for two downstream subnets just for that in addition to an upstream interface. The router in my home, a Cisco 881W, could conceivably have five subnets on as many interfaces in addition to whatever is on the ISP-facing interface. I could imagine this requiring some jiggling of the DHCP-PD spec. As I recall, it (RFC 3633 section 10) allocates a prefix with a length, and allocates from that prefix to a variety of its own interfaces and potentially others. A router asking for 5 /64s will in fact ask for, and receive, one /61. If we want it to literally ask for a list of /64s, I think we have to play with it a bit. I suppose the IA_PD could contain multiple of those options; maybe that's the work-around. What would actually be topical and helpful would be specific comments on the draft in question. What that it says do you object to, and what do you wish it would say? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Feb 25, 2013, at 16:28 , Lorenzo Colitti lore...@google.com wrote: On Tue, Feb 26, 2013 at 4:21 AM, james woodyatt j...@apple.com wrote: As a result, it means that Automatic Prefix Management here is basically unable to do it statelessly, i.e. by randomly generating subnet numbers from an identifier space of conventional size and testing for collision before using them. Why do you say this? Assuming the ISP(s) providing service to the home assign enough space to number all the links (e.g., /60, /56, or /48), then what's the problem? p1. I don't believe it's reasonable to assume that service providers will always provide a short enough prefix to number all the links in a subscriber's network, or that those that currently do will continue to do so into the foreseeable future, or that they will even give notice prior to reducing the space delegated to a subscriber. p2. In a decent sized subscriber network, with several subnets in place, a /56 delegation means a small but significant changes that a randomly selected subnet identifier will collide with an existing one, whenever a router joins the network. With a /60, the odds climb quite a bit, and in some networks it will be 15/16. (Do not make the mistake of assuming that router joins and leaves will be infrequent events. Plan for them happening several times per second, or you will be sorry later.) p3. All this pain can be traded away for the reasonably well-understood pain of NAT66 and a single ULA prefix with a constant 16-bit subnet identifier space, where collisions will be rare and stateless prefix autoconfiguration will settle quickly basically every time. I personally don't think that's a good trade, but if routed home networks are ever to become the normal setup, then I'm very skeptical that my opinion will turn out to be the majority one. I think if we want to avoid the temptation of subscribers to deploy NAT66 to preserve the stability of their 16-bit subnet identifier space in the face of service providers enhancing their choices with a variety of plans with varying policies for prefix delegation, then we have to do it with a stateful subnet manager in the network, near the border gateways. -- james woodyatt j...@apple.com core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon mel...@fugue.com wrote: The alternative is basically a vicious circle: if ISPs ignore the IETF's advice and assign a /64 because they see additional address space as an upsell opportunity, then someone will figure out how to share the /64 by using ugly hacks like routing /128s assigned from DHCPv6. That might be what you imagine someone will do, but what they almost certainly will actually do is just bridge. Math is hard. Yes, bridging will work because if everything is on one link, DAD will avoid collisions. My point was that there is no way to do routing, even with NPTv6, unless enough address space is assigned to the network. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
Sent from ipv6-only Android On Feb 26, 2013 1:54 PM, Cameron Byrne cb.li...@gmail.com wrote: Sent from ipv6-only Android On Feb 26, 2013 11:53 AM, Lorenzo Colitti lore...@google.com wrote: On Tue, Feb 26, 2013 at 12:46 PM, Ted Lemon mel...@fugue.com wrote: The alternative is basically a vicious circle: if ISPs ignore the IETF's advice and assign a /64 because they see additional address space as an upsell opportunity, then someone will figure out how to share the /64 by using ugly hacks like routing /128s assigned from DHCPv6. That might be what you imagine someone will do, but what they almost certainly will actually do is just bridge. Math is hard. Yes, bridging will work because if everything is on one link, DAD will avoid collisions. My point was that there is no way to do routing, even with NPTv6, unless enough address space is assigned to the network. Sorry for silly question. But ...is there a pointer to why routing is desired in the home ? Did homenet document usecases for this ? Ok. I see it in the charter. I dont find it particularly appealing or worth a great trade off for the level of complexity involved. Especially if the tradeoffs require nat66 or something similarly complex CB Cb ___ 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] automatic prefix management (OSPF or ISIS version)
On 22/02/2013 21:11, james woodyatt wrote: 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 I think you must have missed the bit where operators and RIRs around the world abandoned the /48 recommendation wholesale. 6177 simply recognised reality. I agree it's a shame, but it was not the IETF's doing. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
On 22/02/2013 16:54, Fred Baker (fred) wrote: ... 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. If Dynamic DNS Update is used, or some equivalent, even that issue would go away. But I think that to the extent that IPv6 addresses will ever appear on a user's screen, having stable values does have a small benefit. Also see the issues raised in draft-ietf-6renum-static-problem, some of which may apply in a homenet. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] automatic prefix management (OSPF or ISIS version)
It might be a sidetrack on the discussion but I'll answer anyway On Fri, Feb 22, 2013 at 10:11 PM, james woodyatt j...@apple.com wrote: 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. As Brian said, it just reflect what RIR already has in place. I was one of those that suggested and argued for the possibility of using /56 for end-users, not only /48. However I still believe /48's are great and I use it for most end-SITES. For end-USERS a /48 is quite an overkill almost any way you consider it, except if you look at it from a very overall point of view like in the situation this mail-thread is about. 256 /64 is more than enough for almost all end-user cases I can dream up. If any end-user have a setup where 256 LAN segments ain't enough, well then it's so big that it should be consider a end-site and we are back to /48. The use case for homenet are those end-users, not end-sites. Or? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ 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 1:11 PM, james woodyatt j...@apple.com wrote: 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. Two thoughts. One: the v6ops result reflects the operational result in the ARIN community: operators there would like to be able to allocate /56 prefixes to smaller customers and /48s to larger ones. If you want castigate someone, castigate them. Two: If randomization within the home is the issue, I'm not sure the difference between a /48 and a /56 is all that significant. We're discussing the ability to pick a half dozen at best out of a much larger field, and arguing against operators that can't see a reason for anything shorter than a /64. You've heard me argue before that prefix length should be an attribute of the service one purchases, much as capacity is: in the home, I suspect that a /60 would suffice for the vast majority of purposes, and I can imagine companies that would not be happy with a /56 but might be happy with a /52. I don't see a technical argument that everyone has to have precisely a /48. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
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] 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] 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] 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
[homenet] automatic prefix management (OSPF or ISIS version)
{possible resend}
Fred,
wrt: draft-baker-ipv6-isis-automatic-prefix-00
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 (and gone through the
process of advertising it and backing things off...), to randomly
decide to be PREFIX2:0123::/64 when it sees PREFIX2?
I.e. the 0123 is identical for the two prefixes?
This seems a desireable (but not required) property that all the
prefixes on a LAN are similar.
--
] 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[
pgp8ycOOyUQvm.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 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. 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
