On 10.5.2014, at 5.51, Dmitry Anipko <dmitry.ani...@microsoft.com> wrote: > Thank you for the comments. In the Homenet scenario you described, I agree on > the substance with what you wrote – if the router can do such formation of > explicit PVDs, it should do that to prevent mix-up of configuration. Such > text can be added into the section 4, example network configuration and > number of PVDs. That said, I don’t think it contradicts to 2.3, because > Implicit PVDs by definition in 2.2. apply only when there the network is > non-PVD aware: > > <Quote> > It is likely that for a long time there may be networks which do not > advertise explicit PVD information, since deployment of any new > features in networking protocols is a relatively slow process. > > When connected to networks, which don't advertise explicit PVD > information, PVD-aware node shall automatically create separate PVDs > for received configuration. Such PVDs are referred to in this > document as "implicit". > </quote> > > So from the host perspective, presence of a router, which can/does advertise > PVDs, makes it a scenario with explicit PVDs, and not implicit ones.
2.2 has also that mixed implicit+explicit mode which I’d rather see die in fire, because it makes the definition just more complicated. I think interface should be either fully explicit, or fully implicit, because mixed mode is a) more complicated, and b) possible to fail (implicit in general does, and mixed doesn’t help here). > >>, I don’t see the point in non-explicit PVDs coming _to_ hosts except > >>perhaps in case of IPv4 > My understanding, is that the main reason we introduced the notion of > implicit PVD is to be able to handle configurations received on multiple > interfaces (which typically are connected to different networks) in the same > way as in the case of multiple explicit PVDs, basically to unify and simplify > conceptual host implementation. The acknowledged limitation is that we don’t > know well how to form multiple implicit PVDs on one interface (or form > implicit PVDs, spanning multiple interface). See my comment above about fail - I’m not convinced implicit PVDs work well in any case. BCP38-ish filtering by upstream ISPs on either normal data traffic or DNS requests, etc => you can’t just pool parameters together implicitly and hope they work. > >> Also, I’d just rather treat PVD-bind as per-interface or per-address one; > >> if we can determine packet doesn’t belong to it (outside the application), > >> application shouldn’t know, and remote node shouldn’t know application is > >> listening to some other PVD. So connection refused/equivalent. > > The current text is > <quote> > If the determined receiving PVD of the packet is not in the allowed > subset of PVDs for the particular app/transport API object, the > packet should be handled in the same way as if there were no listener > (alternatives - error message 'administratively prohibited', or just > refer to pre-PVD behavior for legacy behavior for interface-scoped > binds). > </quiote> > > It seems the case you described would be where the “allowed subset of PVDs” > contains only one PVD. If you think the current text is not sufficient, can > you please suggest the change? Well, I’m mostly concerned about complexity of that whole section - having dealt with brokenness of cross-platform dual AF IPv6 sockets recently[1], I’m not very keen to have very complicated semantics anywhere. All of that reverse-RPF stuff etc sounds just overkill to me (and potentially harmful, if you assume someone actually has PI address space coming from multiple connections). If it was up to me, I’d get rid of cross-PVD filtering stuff altogether and leave it as exercise to firewall vendor or whoever really cares. I don’t see it affecting the PVD semantics in any way, except adding extra text. So: concrete proposal - nuke second paragraph, remove alternatives from third paragraph. Cheers, -Markus _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
