On 29 feb 2008, at 2:36, Templin, Fred L wrote: > Having read further now, I think I get what is being > proposed. As I mentioned before, I have also suggested > adding MTU info in IPv6 ND messages in past efforts:
> http://www.potaroo.net/ietf/idref/draft-templin-v6v4-ndisc/ > http://www.potaroo.net/ietf/idref/draft-templin-ndiscmtu/ I saw one of them before, yes. But the approach is fairly different. > If I get what is being proposed, I believe the mechanisms > you are proposing may be useful in conjunction with SEAL. > The reason I asked about the router-to-router is that > that is the SEAL use case, and it would be "interesting" > to see whether the loose interpretation of RS/RA you are > making could be applied between a pair of routers at > either end of a virtual link such as for the SEAL > ingress/egress tunnel routers. Right. That should work well if neighbor discovery is performed through the tunnel, which is fairly common from what I've seen. One issue would be that if the tunnel gets rerouted, the MTU can change. The draft currently only catches that with dead neighbor detection, which routers on tunnel endpoints can't do... So that could be a problem. In theory the same problem can happen on a layer 2 network but in practice that wouldn't happen very easily. > 1) Section 1, text beginning: "However, [RFC4821] must > be implemented in every transport protocol...", I'm not > sure I understand/agree with the point. My understanding > of RFC4821 was that incremental deployment was supported. Well, if you have RFC 4821 in your TCP implementation that doesn't buy you anything for NFS or DNS with EDNS0 over UDP. It's incremental in the sense that you can deploy it where it's not deployed and things get better. But in the case of my draft, we make things worse by removing the fixed MTU so if you then repair that with something that doesn't cover 100% of all cases, you're left with a certain number of cases where there will be problems. > Also, I don't understand the part about "significant > probability for failures"? "if hosts implementing [RFC4821] interact with hosts that don't implement this mechanism but do use a larger than standard MTU." Suppose host A lives on a subnet with variable MTUs and host B lives on a different subnet with a manually configured jumboframe MTU. If A and A's router support probing as outlined in the draft, then everything will work. However, suppose there is a switch on the network that doesn't support A's MTU. Without the probing defined in the draft, A can still discover what packet size it can use towards B, but the router doesn't see that A can't successfully receive the large packets that B sends to it can't send back a too big, and B doesn't implement RFC 4821 so if it sends large packets, it can't recover from the path MTU discovery black hole. > 2) Section 4.1 and onwards, I'm not so sure about the > "SLOWMTU" applicability. IMHO, the mechanisms in this > document should be useful whether the receiver of the > RA is directly connected to the same physical link as > the router that sent it, or whether there are potentially > many physical links with different properties in the > path (e.g., when the subnet spans multiple bridged links.) Absolutely. But what does that have to do with SLOWMTU? The idea behind SLOWMTU is twofold: it could be that the slow hosts are behind switches that don't support the larger MTU, and even if the slow hosts COULD send large packets, that may be undesirable because it increases RTTs and jitter. > 3) Section 4.2, perhaps this text is part of what you were > meaning about being careful about node, host, route, etc. > Particularly interesting is the part beginning: "Devices > not acting as IPv6 routers ... MAY send out a router > advertisement ...". I think this is worth considering, > and also worth considering is whether two routers connected > by a virtual link that spans an interdomain routing region > (default-free, perhaps) can mutually send RAs with multi-MTU > options to one another (with Router Lifetime=0, of course). Why would they send out router advertisements? The information about the supported MTUs is available in neighbor solicitations/ advertisements, which routers DO send to each other. > The Ras might also contain RFC4191 RIOs, but no RFC4861 PIOs > and such. Hey, a new neighbor discovery RFC... Managed to miss that. RIO = route information option, PIO = prefix information option (or something like that)? Note that these acronyms don't appear in those RFCs. I think it could be useful for routers to advertise a maximum packet size for the default route, or at least, indicate that large packets can't be used there. The downside is that you can then only use them on the local subnet, unless you start adding them to RFC 4191 information... Sticking to PMTUD is simpler. Packet sizes aren't dependent on addresses so in the prefix options wouldn't make much sense, IMO. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
