Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
A host SHOULD select a default gateway for each prefix it uses to obtain one of its own addresses. That router SHOULD be one of the routers advertising the prefix in its RA. As a result of doing so, when a host emits a datagram using a source address in one of those prefixes and has no history directing it otherwise, it SHOULD send it to the indicated default gateway. The question is to which one (if there are multiple): this might be important for e.g. fail-over cases or if you want to dynamically optimize away that extra hop you mention. yes, that text should be changed to accommodate multiple default routers. ref rfc4311. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Am 10.08.2015 um 19:28 schrieb Fred Baker (fred): In any event, I would urge the HNCP design team to consider the cases, and either make an argument that making network routing more complex (BCP 84) has a benefit I'm missing and actually works without the rule, or change HNCP to not have each RA contain every possible prefix. After scanning the discussions here, is there anything in particular that people feel which we need to add or clarify in HNCP for that matter? It seems to me that the current behavior, i.e., potentially non-optimal router sending out the PIO and then relying on redirection / routing does not really break things. Optimizing the PIO sending might in theory be possible but - as pointed out - is probably very hard to accomplish in practice. In addition, as a personal note from my own reading, I'm not 100% convinced that hosts even following the next-hop tracking of 6724 would correctly react to potential handover of a PIO from one router to another since the definition is relatively vague. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On 16/08/2015 21:31, Steven Barth wrote: Am 10.08.2015 um 19:28 schrieb Fred Baker (fred): In any event, I would urge the HNCP design team to consider the cases, and either make an argument that making network routing more complex (BCP 84) has a benefit I'm missing and actually works without the rule, or change HNCP to not have each RA contain every possible prefix. After scanning the discussions here, is there anything in particular that people feel which we need to add or clarify in HNCP for that matter? It seems to me that the current behavior, i.e., potentially non-optimal router sending out the PIO and then relying on redirection / routing does not really break things. I think Pierre was saying in Prague that it does break things in the case of extra hops on very lossy wireless networks. Optimizing the PIO sending might in theory be possible but - as pointed out - is probably very hard to accomplish in practice. In addition, as a personal note from my own reading, I'm not 100% convinced that hosts even following the next-hop tracking of 6724 would correctly react to potential handover of a PIO from one router to another since the definition is relatively vague. That is probably true today but hopefully doesn't have to stay true for the next hundred years. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Aug 13, 2015, at 8:21 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I think all we have to do is delete 'on-link' in the second paragraph. (The 'generally' in the first paragraph allows for the exceptional case that Mikael was concerned about, I think.) I'll give people a couple of days to comment further, but that change is locked into the next version. signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Ole Troan wrote: Mikael, in the land of contrived examples! :-) this working groups answer to the below is make this a homenet and run HNCP. then the host rule enhancement isn’t used. in any case let me try to reply below, although I’m quite confused about the example. two PIO’s of different length on the link sounds like a configuration error. Then I must still be missing something. Example time: A B+-+F + + | | ++-++ | | + + C D + | + E A, B and D are routers. A has received a /56 from ISPA. D has been delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also advertising ISPA /56 as off-link to indicate that it'll handle the entire /56. currently, advertising a PIO with L=0 isn’t a routing advertisement (“handle the prefix”?). it only affects a hosts prefix list and how it does onlink determination for addresses in that prefix. i.e. a host would first chose D and NH, then find a suitable source. with the new rule, the PIO becomes more like a source constrained route. “for any source address matching prefix in PIO, send traffic to me”. I don’t understand what you would gain from the ISPA/56 PIO over the ISPA/64 you’d have in C already. Because the DHCPv6 IA_NAs handed out to C (by A or a DHCPv6 server on the ABCD link) isn't in any on-link PIO. So without the /56, C has no idea it needs to send these packets to A to avoid BCP38 filtering (in case for instance B is announcing ISPB prefixes). Now, do we want D to do anything to tell C that E is reachable through D? Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and let all traffic from C to D bounce via A? Do we want A to in some way announce the delegated /64 IA_PD prefix? 1) run homenet / routing protocol That won't tell C anything, but ok, fine. 2) absolutely not 3) RIO with router lifetime of 0 could work but geez this is what homenet solves 4) yes 5) no What do we want A to do, should it announce the /120 as off-link? On-link might make sense in this case. that would only affect hosts on the ABCD link. D would still send all traffic for the /120 to A (as default route) Yes. I don’t see that you need either. How will C know whereto send packets sourced from its IA_NA address? /64 on-link PIO from A for the on-link ABCD /64 prefix yes. /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix possibly. probably not needed. How will C know whereto send packets sourced from its IA_NA address? As far as I can tell, you need either covering /56 or announcing the /120 (remember, this /120 it not within a /64 that there is a PIO for if you don't announce the /56 as an L=0 PIO). Again, my problem is that I don't see how IA_NA (or IA_PD in case it's a router) outside encompassing PIO can get correctly routed. And again, this is a valid deployment scenario. So either we say MUST announce PIO with L=0 or L=1 for all addresses that a host will have, or things will not work. I also want to be able to solve RFC7084-style DHCPv6 IA_PD requesting router to send packets from hosts behind it to the correct upstream, so I would like this case adressed as well. Announcing the entire PIO /56 L=0 that the A router has been delegated would solve this problem, yes? And if there is a /56 and /64 that are overlapping, do longest prefix matching on the PIO and choose that NH. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On 13/08/2015 17:23, Mikael Abrahamsson wrote: On Thu, 13 Aug 2015, Brian E Carpenter wrote: I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case. I think we're saying: there needs to be a PIO if it matters which first-hop router such a host picks. If it doesn't matter (i.e. there is a complete local routing cloud with SADR, or there is no BCP 38 filter) then the host can use any first-hop router it wants. Can it be an L=0 PIO? I would think so. L=0 conveys no information, after all, according to RFC 4861: When not set the advertisement makes no statement about on-link or off-link properties of the prefix. So I think the -01 draft is wrong, since it says on-link. Brian How the router knows to send that PIO is not a problem for the host, therefore not in scope in this draft. (But there's no doubt in my mind that life is simpler if you don't use DHCPv6.) Of course, but the use-case of having IA_NA that isn't covered by an on-link PIO Is useful in some scenarios (where for instance you have configured the L2 network so that devices can't talk directly to each other, and you want to make the L3 configuration reflect this so you don't have to do magic tricks like local-proxy-arp (whatever that would be called in IPv6)). ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Aug 13, 2015, at 7:37 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: So I think the -01 draft is wrong, since it says on-link. What is says is A host receives prefixes in a Router Advertisement [RFC4861], which goes on to identify whether they are usable by SLAAC [RFC4862] [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the Router Advertisement would normally signal the availability of DHCPv6 [RFC3315] and the host would use it to configure its addresses. In the latter case it will be generally the case that the configured addresses match one of the prefixes advertised in a Router Advertisement that are supposed to be on-link in that subnet. Since the host derives fundamental default routing information from the Route Advertisement, this implies that, in any network with hosts using multiple prefixes, each prefix SHOULD be advertised via on-link Prefix Information Options [RFC4861] by one of the attached routers, even if addresses are being assigned using DHCPv6. A router that advertises a prefix indicates that it is able to appropriately route packets with source addresses within that prefix. Tell me what to make it say. signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On 14/08/2015 14:46, Fred Baker (fred) wrote: On Aug 13, 2015, at 7:37 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: So I think the -01 draft is wrong, since it says on-link. What is says is A host receives prefixes in a Router Advertisement [RFC4861], which goes on to identify whether they are usable by SLAAC [RFC4862] [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the Router Advertisement would normally signal the availability of DHCPv6 [RFC3315] and the host would use it to configure its addresses. In the latter case it will be generally the case that the configured addresses match one of the prefixes advertised in a Router Advertisement that are supposed to be on-link in that subnet. Since the host derives fundamental default routing information from the Route Advertisement, this implies that, in any network with hosts using multiple prefixes, each prefix SHOULD be advertised via on-link Prefix Information Options [RFC4861] by one of the attached routers, even if addresses are being assigned using DHCPv6. A router that advertises a prefix indicates that it is able to appropriately route packets with source addresses within that prefix. Tell me what to make it say. I think all we have to do is delete 'on-link' in the second paragraph. (The 'generally' in the first paragraph allows for the exceptional case that Mikael was concerned about, I think.) Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Below... On 13/08/2015 06:42, Mikael Abrahamsson wrote: On Wed, 12 Aug 2015, Ole Troan wrote: For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix. I take it IA_PD was included above by mistake. No. This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix. true. but I’m not sure what bearing that has with the host rule in question. I’m also wondering if you are making a wrong assumption of what an L=0 PIO entails. I don't know. Am I? I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case. I think we're saying: there needs to be a PIO if it matters which first-hop router such a host picks. If it doesn't matter (i.e. there is a complete local routing cloud with SADR, or there is no BCP 38 filter) then the host can use any first-hop router it wants. How the router knows to send that PIO is not a problem for the host, therefore not in scope in this draft. (But there's no doubt in my mind that life is simpler if you don't use DHCPv6.) Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Thu, 13 Aug 2015, Brian E Carpenter wrote: I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case. I think we're saying: there needs to be a PIO if it matters which first-hop router such a host picks. If it doesn't matter (i.e. there is a complete local routing cloud with SADR, or there is no BCP 38 filter) then the host can use any first-hop router it wants. Can it be an L=0 PIO? How the router knows to send that PIO is not a problem for the host, therefore not in scope in this draft. (But there's no doubt in my mind that life is simpler if you don't use DHCPv6.) Of course, but the use-case of having IA_NA that isn't covered by an on-link PIO Is useful in some scenarios (where for instance you have configured the L2 network so that devices can't talk directly to each other, and you want to make the L3 configuration reflect this so you don't have to do magic tricks like local-proxy-arp (whatever that would be called in IPv6)). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. the rule we are proposing is something like: “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” the subnet model in IPv6 assumed that all routers on a link had equal reachability. this rules solves the case where there are two routers with different reachability (and addressing) on a single link. currently hosts that don’t do implement this, typically suffer from long time outs and broken connectivity. with the above rule I don’t see how offlink/onlink or DHCPv6 makes any difference. if there isn’t a PIO, well then the host is left uninformed. can you construct an example where the rule breaks things and that not having the rule wouldn’t? cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Ole Troan wrote: Mikael, Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. the rule we are proposing is something like: “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” Check. And PIO here can be RIO as well? What about if there are several PIO/RIOs of different size, do we do longest matching on them to prefer one? Or shortest because the guy with the shortest prefix (not /0) is more likely to be the one closest to the uplink? can you construct an example where the rule breaks things and that not having the rule wouldn’t? No, I am still trying to figure out exactly what is being proposed. Next step is to try to come up with something that'll make things break. -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Juliusz Chroboczek wrote: Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals? I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6. Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't have to be covered by an on-link prefix. You don't get any SLAAC based addresses without an on-link RA for the prefix with A=1. So this is obvious that there needs to be an RA sent. For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix. This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. the rule we are proposing is something like: “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” Check. And PIO here can be RIO as well? no, I don’t think it can. the RIO says nothing about the link itself. What about if there are several PIO/RIOs of different size, do we do longest matching on them to prefer one? Or shortest because the guy with the shortest prefix (not /0) is more likely to be the one closest to the uplink? two PIO’s of different length on the link sounds like a configuration error. can you construct an example where the rule breaks things and that not having the rule wouldn’t? No, I am still trying to figure out exactly what is being proposed. Next step is to try to come up with something that'll make things break. good. ;-) cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
“In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” It took me a while to decode that. If anyone else is as stupid as I am, here's the translation When selecting the (source, destination, next-hop) triple among available routes for a given destination prefix, prefer one whose next-hop is a router that sent an RA with a prefix that covers the source address under consideration. Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals? I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6. Sorry for the bother. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Wed, 12 Aug 2015, Ole Troan wrote: two PIO’s of different length on the link sounds like a configuration error. Then I must still be missing something. Example time: A B+-+F + + | | ++-++ | | + + C D + | + E A, B and D are routers. A has received a /56 from ISPA. D has been delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also advertising ISPA /56 as off-link to indicate that it'll handle the entire /56. Now, C takes itself a couple of addresses from the ABCD /64 (because A=1) and does DHCPv6 IA_NA. A then hands it an address from outside the /64 (because that was configured for some reason). A has a /120 route pointing to its interface that ABCD sits on, so that this DHCPv6 IA_NA works (because it's outside the on-link /64). D is a RFC7084 router and has requested IA_PD from A and received another /64, which it then uses to put on the DE link. Now, do we want D to do anything to tell C that E is reachable through D? Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and let all traffic from C to D bounce via A? Do we want A to in some way announce the delegated /64 IA_PD prefix? What do we want A to do, should it announce the /120 as off-link? On-link might make sense in this case. B has F behind it, I guess we want this to get an address as well, from ISPA prefix. Do we want B to send out an RIO for this /64? So for C, the world view might now look like this: /56 RIO or PIO (depending on what we want to do) for ISPA prefix /64 on-link PIO from A for the on-link ABCD /64 prefix /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix /64 RIO (?) from D for its DE /64 /64 RIO (?) from B for its BF /64 Or do we want above RIOs to be off-link PIOs instead? -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix. I take it IA_PD was included above by mistake. No. an IA_PD prefix is by definition not assigned to the link between RR and DR. This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix. true. but I’m not sure what bearing that has with the host rule in question. I’m also wondering if you are making a wrong assumption of what an L=0 PIO entails. I don't know. Am I? I still don't understand what a host with an IA_NA or IA_PD that isn't covered by an on-link PIO should do with a packet sourced from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid case. are you talking about something different than 3633 DHCPv6 prefix delegation? if the SA doesn’t match a PIO on link, then the next-hop on that interface is chosen like it is today. if you’re inventing new stuff like host IA_PD derived addresses, then that’s something someone has to specify. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Juliusz, “In SA, DA, NH selection, prefer the NH that has advertised a PIO covering the SA” It took me a while to decode that. If anyone else is as stupid as I am, here's the translation When selecting the (source, destination, next-hop) triple among available routes for a given destination prefix, prefer one whose next-hop is a router that sent an RA with a prefix that covers the source address under consideration. thanks for the readable version! ;-) now, can you please write one for hosts that only have a Default Router List (as in no routing table). (I don’t object if we only describe the conceptual host model for type C (4191) hosts though. Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals? I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6. I’ll try. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, in the land of contrived examples! :-) this working groups answer to the below is make this a homenet and run HNCP. then the host rule enhancement isn’t used. in any case let me try to reply below, although I’m quite confused about the example. two PIO’s of different length on the link sounds like a configuration error. Then I must still be missing something. Example time: A B+-+F + + | | ++-++ | | + + C D + | + E A, B and D are routers. A has received a /56 from ISPA. D has been delegated a /64 from this ISPA prefix using DHCPv6 IA_PD. A is advertising a /64 from ISPA with A=1,L=1, and also advertises M=1 for the ABCD link. A is also advertising ISPA /56 as off-link to indicate that it'll handle the entire /56. currently, advertising a PIO with L=0 isn’t a routing advertisement (“handle the prefix”?). it only affects a hosts prefix list and how it does onlink determination for addresses in that prefix. i.e. a host would first chose D and NH, then find a suitable source. with the new rule, the PIO becomes more like a source constrained route. “for any source address matching prefix in PIO, send traffic to me”. I don’t understand what you would gain from the ISPA/56 PIO over the ISPA/64 you’d have in C already. Now, C takes itself a couple of addresses from the ABCD /64 (because A=1) and does DHCPv6 IA_NA. A then hands it an address from outside the /64 (because that was configured for some reason). A has a /120 route pointing to its interface that ABCD sits on, so that this DHCPv6 IA_NA works (because it's outside the on-link /64). D is a RFC7084 router and has requested IA_PD from A and received another /64, which it then uses to put on the DE link. Now, do we want D to do anything to tell C that E is reachable through D? Like announce in RAs an off-link /64? Or announce an RIO? Or do nothing and let all traffic from C to D bounce via A? Do we want A to in some way announce the delegated /64 IA_PD prefix? 1) run homenet / routing protocol 2) absolutely not 3) RIO with router lifetime of 0 could work but geez this is what homenet solves 4) yes 5) no What do we want A to do, should it announce the /120 as off-link? On-link might make sense in this case. that would only affect hosts on the ABCD link. D would still send all traffic for the /120 to A (as default route) B has F behind it, I guess we want this to get an address as well, from ISPA prefix. Do we want B to send out an RIO for this /64? you want B to run homenet. So for C, the world view might now look like this: /56 RIO or PIO (depending on what we want to do) for ISPA prefix I don’t see that you need either. /64 on-link PIO from A for the on-link ABCD /64 prefix yes. /120 on-link PIO from A for the on-link ABCD DHCPv6 IA_NA prefix possibly. probably not needed. /64 RIO (?) from D for its DE /64 /64 RIO (?) from B for its BF /64 Or do we want above RIOs to be off-link PIOs instead? they would be RIOs. since you want destination routes, and not source routes. in (D,S) SADR notation. a RIO: (DE/64, *) while PIO: (::/0, DE/64) please use homenet protocols. don’t build networks like this! cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Mikael, Ole, Mikael, could either of you please summarise the discussion you're having for us mere mortals? I don't understand what problem you're trying to solve, and I don't understand why you're distinguishing between SLAAC and DHCPv6. Because a DHCPv6 IA_NA and DHCPv6 IA_PD doesn't have to be covered by an on-link prefix. You don't get any SLAAC based addresses without an on-link RA for the prefix with A=1. So this is obvious that there needs to be an RA sent. RA’s are sent regardless of DHCP or SLAAC. you can do SLAAC with A=1, L=0. For DHCPv6 these contraints do not apply anymore. That's what I'm trying to figure out, how do we handle these IA_NAs and IA_PDs that are not within an on-link RA being sent for that prefix. I take it IA_PD was included above by mistake. This is definitely not a configuration error, it's perfectly valid to hand out single address using DHCPv6 IA_NA that isn't covered by an off-link or on-link prefix. true. but I’m not sure what bearing that has with the host rule in question. I’m also wondering if you are making a wrong assumption of what an L=0 PIO entails. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Tue, 11 Aug 2015, Ole Troan wrote: Your document describes (in my opinion) desireable behaviour for devices going forward. I would like to see text for DHCPv6 as well, both IA_NA and IA_PD, if the same kind of behaviour can work there somehow. This is out of scope for homenet though. the rule applies regardless of how the addresses have been assigned. Yes, but how will the router signal that it'll handle addresses for a certain prefix, for instance a /56 from where DHCPv6 IA_NA and IA_PD is being assigned, but that isn't onlink? Advertising that /56 as an off-link prefix hasn't historically said I'll handle Internet traffic for source addresses within all prefixes that I announce, both offlink and on-link. Perhaps we can say that it does, but it's not obvious to me that there are no corner cases for this that'll break things. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-00 Something that homenet, and specifically HNCP, might be interested to consider is the impact of egress/SADR routing as discussed in this draft on its recommendations. The draft is in WGLC and in need of a revised draft, so you may consider this a late comment or a WGLC comment as you please. Or, tell me that the person who raised the question to me is incorrect. It has been pointed out to me that HNCP expects that every router in a homenet network will advertise every PA or PI prefix in use in the network. This creates two issues. The recommended host behavior is to have a host that has an address in each of two or more prefixes (which, note, might be on the same interface or on different ones) is to have it originate traffic using a given source prefix to the router, or one of the routers, that advertised the prefix to it. In the simplest case, which would be to have one or more hosts on a LAN with two or more routers connected to as many upstream networks, would have the network avoid BCP 84 routing among the routers, but instead have a host present a packet to the router the packet needs to use. A more general case is exemplified in my home office. Due to Cisco Information Security rules, my office is effectively part of and served by Cisco's corporate network, while my home is served by my ISP. There is physically one router, but it is configured in two slices, and packets don't travel between the slices. So conceptually - and there is no reason this couldn't be physical - there are two separate routers. If I turn on the WiFi interface on my laptop, I now have a Cisco address on the Ethernet port and an ISP address on the WiFi port. I can expect both Cisco and the ISP to implement BCP 38 (discarding traffic that has the wrong source address), and there is no mechanism or connectivity by which a packet with one of the two prefixes might be redirected (BCP 84) to the other router. I am absolutely dependent on my host guessing correctly - absent this rule. The first issue is that, absent this rule, we are absolutely dependent on Happy Eyeballs processing to even get a packet out of the door. The second issue, and this one I'm unsure about but raise in case there is an issue, has to do with the process of removing a prefix from a network. It seems likely that we have a counterpart to RIP's count-to-infinity problem, except that there is no counter to rely on. If a router advertising a prefix into a network decides to withdraw it, the last router in the network that maintains knowledge of it has some possibility of re-infecting the network with it. I think you want the advertisement of a prefix in an RA to be tightly linked to its current allocation status and lifetime. In any event, I would urge the HNCP design team to consider the cases, and either make an argument that making network routing more complex (BCP 84) has a benefit I'm missing and actually works without the rule, or change HNCP to not have each RA contain every possible prefix. I'll draw a picture to help understand the case. There are two upstream ISPs, which I'll call ISP-Alice and ISP-Bob. In the home, there are two LANs, three routers (Alice, Bob, and Carol), two LANs, and two hosts (Spanky and Alfalfa): +---++--+ | || | |ISP-Alice ||ISP-Bob | | || | | || | +--+++-++ | | +--+--+ +-+-+ |Alice| |Bob| +--+--+ +-+-+ | | ++-+--+++ || +--+---+ +--+--+ |Spanky| |Carol| +--+ +--+--+ | +++-+ | +--++ |Alfalfa| +---+ If every router is responsible to announce prefixes from ISP-Alice and ISP-Bob on every LAN, then Spanky has a distinct probability that, to get a packet to ISP-Alice, it will send it to ISP-Bob, who will then have to redirect it to ISP-Alice. If on that LAN, Alice advertises the ISp-Alice prefix and Bob advertises the ISP-Bob prefix, and Spanky presents the packet to the router that advertised its source prefix, Spanky will invariably present such a packet to Alice. On the second LAN, Carol will of course have to announce both prefixes, and use SADR routing to get the packet to the right egress router. But Alfalfa doesn't need to know the details; he learned both prefixes from Carol and presents all packets to her. signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Aug 10, 2015, at 12:02 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I'm not sure if I read you right, but I assume you are concerned about what happens when a delegated prefix is retraceted. (The ISP stops the delegation, or the DHCPv6-PD client decides to hide the prefix from the rest of the Homenet). In that case, the DHCPv6-PD client refloods its set of delegated prefixes, which triggers the prefix assignment algorithm, which causes the APs in the retracted DP to be retracted. OK, that should work. The first issue stands. signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
Fred, Add another LAN interface to Alice, connecting host Porky. If Alice didn’t advertise both ISP-Alice and ISP-Bob prefixes, Porky couldn’t use ISP Bob. It would be a quite complicated set of rules determining when Alice should or should not include ISP Bob’s prefixes on a given link. I’m quite uncomfortable tying Router Advertisement PIO’s to routing and topology changes. I think Brian makes a good point on slide 9: https://www.ietf.org/proceedings/93/slides/slides-93-6man-6.pdf +---++———+ | || | |ISP-Alice ||ISP-Bob | | || | | || | +--+++-++ | | +--+--+ +-+-+ |Alice| |Bob| +--+--+ +-+-+ | | ++-+--+++ || +--+---+ +--+—+ |Spanky| |Carol| +--+ +--+———+ | +++——+ | +--+——+ |Alfalfa| +———+ cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
On Aug 10, 2015, at 10:28, Fred Baker (fred) f...@cisco.com wrote: If every router is responsible to announce prefixes from ISP-Alice and ISP-Bob on every LAN, then Spanky has a distinct probability that, to get a packet to ISP-Alice, it will send it to ISP-Bob, who will then have to redirect it to ISP-Alice. If on that LAN, Alice advertises the ISp-Alice prefix and Bob advertises the ISP-Bob prefix, and Spanky presents the packet to the router that advertised its source prefix, Spanky will invariably present such a packet to Alice. To send a packet through ISP-Alice, it suffices for Spanky to send to any default router on its link that has a source-specific route for ISP-Alice through Alice, which HNCP seems to be capable of insuring that Bob will have if it’s smart enough to be advertising in its RA messages a prefix assigned from one of Alice’s delegations. Admittedly, this might not be optimal— a direct path from Spanky through Alice to ISP-Alice might perform better, as the section on Residual Issues in the draft notes— but there isn’t any obvious way currently defined to signal to hosts that a particular default router should be preferred over others for packets sourced from addresses corresponding to a Prefix Information Option. It may be tempting to think that conformance with RFC 6724 could help in the case where routers are coordinating to advertise only the assigned prefixes for which they are currently the best default router, but I suspect that it isn’t so simple and serious complications involving topology reconfiguration and RA timeouts can arise. I think that’s a general problem not specific to HOMENET, and 6MAN should decide what to think about I-D.baker-6man-multi-homed-host accordingly. —james___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
