Hello Markus, Thank you for the comments.
>> Is this meant to be IPv6-only? Because most typical hosts allow only one >> IPv4 address per interface, and that leads to NATs and all sorts of fun >> stuff. 2.5 refers to dual stack, and there's references to IPv4, but e.g. >> 5.2.3.1 example using the address as determinant of PvD sounds bit stretched >> unless you really can provision multiple IP addresses for v4 too. Host | Router - ISP1 | ISP2 >> How is this supposed to work with IPv4, and say, 2 ISPs and one VPN >> connection? (I can guess, but document doesn't really say.) [danipko] I think the text was written with the assumption in mind that different PvDs can provide different addresses, which should be the case in IPv6, and in some topologies with IPv4. If you have a proposal that works for the topology you described, where presumably the Router performs address assignment (and does NATing?), please feel free to describe it. >> I'm still not happy with mixed mode definition in 2.2 - it explicitly _does_ >> limit to one implicit PvD per link. [danipko] I will change the text to further clarify that multiple implicit are allowed. >> What's wrong with IPv4/IPv6 PvDs being distinct in any case? Given good >> multi-PvD support, what's the problem? [danipko] My understanding is that in order for things like DHCPv6 prefix policy option to work, the respective IPv4 and IPv6 connectivity need to be considered within a context of the single PvD. Having IPv4 and IPv6 from the same administrator to be in different PvDs seems to increase complexity, and e.g. break the scenario with the prefix policy, while the benefits of putting in different PvDs are unclear. Can you elaborate on why you think the default of putting IPv4 and IPv6 into separate implicit ones makes more sense than into single implicit one? >> Does the explicit PvD ID have to be really globally unique or just low >> chance of collision (like ULA or the implicit PvD)? [danipko] IIRC there was a discussion in London on this question, but I don't believe there was any better proposal for the arch doc compared to the current wording. My 2 cents is that I would not object to change the current wording to something like "or otherwise, an ID with high probability of being unique", if that has consensus. For those types of PvD IDs (to be defined in a separate design doc), where the ID is tied to e.g. DNS suffix and a cert, global uniqueness would be assured through those means (an attacker can try to fake the ID, but it won't be trusted, and hence the PvD may be ignored by the host). >> 2.3: s/one interfaces/one interface/ 3.3: [refs to X and Y] 4: the section title is bit misleading I think - I'd just remove 'and number of PVDs' 4.1/4.2: '- one' - I'd just remove the -, or better yet, rework out the parentheses too.. [danipko] OK. -Dmitry -----Original Message----- From: Markus Stenberg [mailto:markus.stenb...@iki.fi] Sent: Tuesday, July 15, 2014 2:42 AM To: Dmitry Anipko Cc: Markus Stenberg; Mikael Abrahamsson; mif@ietf.org Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-02.txt .. back from my vacation, also rereading from scratch. On 8.7.2014, at 1.34, Dmitry Anipko <dmitry.ani...@microsoft.com> wrote: >>> 2.3. Does the current writing prohibit that multiple implicit PVDs are >>> formed on a single interface, for instance if RAs are seen from two or more >>> routers on the same link, each announcing non-overlapping address space and >>> DNS resolvers? I would like to see a PVD being formed for each of these to >>> also allow for source based routing to send packets / use each resolver >>> depending on what source address based on these RAs are being used. > IIRC the WG discussed this question on a couple of occasions, and my > understanding of consensus is: while there is no intent to prohibit multiple > implicit PvDs on an interface, there is no clear way how to enable the > implicit PvDs with finer granularity either. The text was supposed to reflect > such position by saying "By default, implicit PVDs are limited... If > additional information is available to the host through mechanisms out of > scope of this document, the host may form implicit PVDs with different > granularity". Do you think this needs more elaboration in the text? (such as > e.g. including your example into that section; this may open questions though > such as e.g., how to make sure that IPv6 & IPv4 from the same router do not > end up in different PvDs) Comments: 2.1/.../5.2.3.1: Is this meant to be IPv6-only? Because most typical hosts allow only one IPv4 address per interface, and that leads to NATs and all sorts of fun stuff. 2.5 refers to dual stack, and there's references to IPv4, but e.g. 5.2.3.1 example using the address as determinant of PvD sounds bit stretched unless you really can provision multiple IP addresses for v4 too. How is this supposed to work with IPv4, and say, 2 ISPs and one VPN connection? (I can guess, but document doesn't really say.) Diagram: Host | Router - ISP1 | ISP2 2.2/2.3: I'm still not happy with mixed mode definition in 2.2 - it explicitly _does_ limit to one implicit PvD per link. What's wrong with IPv4/IPv6 PvDs being distinct in any case? Given good multi-PvD support, what's the problem? Same thing with 2.3 too - why not have implicits be next hop based by default? (Similarly in 2.5 - it seems to confuse interface and next hop :-p) 2.4: Does the explicit PvD ID have to be really globally unique or just low chance of collision (like ULA or the implicit PvD)? Constructing one that is globally unique _and_ human readable may be tricky. Is there some construction here that (for average human) is human readable and guaranteed to be globally unique? FQDN or AS# or something derived from prefix do not really count here I think. And some combination of $MEGACORP and $SERVICE is not guaranteed to be unique either. The point I'm trying to make is that e.g. 'LameISP SlowSpeed' is human readable, but has just 'some' global uniqueness guarantee. slowspeed.lamepsi.example.com can be made globally unique, but at expense of readability. 7.1: Not really serious comment as such, but I think there's some heartwarming trust here towards ISP that actually uses 'trust' mechanism with a customer not to do evil things ;-) My nits: 2.3: s/one interfaces/one interface/ 3.3: [refs to X and Y] 4: the section title is bit misleading I think - I'd just remove 'and number of PVDs' 4.1/4.2: '- one' - I'd just remove the -, or better yet, rework out the parentheses too.. Cheers, -Markus _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
