Iljitsch, 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/ 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. A couple of specific comments about your doc: 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. Also, I don't understand the part about "significant probability for failures"? 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.) 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). The Ras might also contain RFC4191 RIOs, but no RFC4861 PIOs and such. What do you think? Thanks - Fred [EMAIL PROTECTED] >-----Original Message----- >From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] >Sent: Thursday, February 28, 2008 2:23 PM >To: Templin, Fred L >Cc: Internet Area >Subject: Re: [Int-area] Multi-MTU subnet draft > >On 28 feb 2008, at 21:08, Templin, Fred L wrote: > >> Apologies on being slow to coming around to reading this. >> Still have to read further, but one question for now: is >> this useful for router-to-router, or is it only used for >> host-to-router (and maybe also host-to-host). For that >> matter, perhaps the definition of what is meant by "host" >> and "router" is somewhat soft? > >It's meant for each of the following cases: > >router-router >router-host >host-host > >I've tried to be careful with using the words "node" and "host". Most >stuff applies both to routers and hosts, but there are a few things >that only hosts can do because they get to determine the size of >packets that are sent, routers have no choice in the matter. >I.e., the >TCP MSS option makes sure a jumbo-capable host doesn't send TCP >segments larger than the standard MTU to a non-jumbo-capable >host, and >RFC 4821 also only works on hosts. > >So should implementers want to keep their life simple and omit the >neighbor discovery options and jumbo ARP, they can take care of the >difference through RFC 4821. But routers can't send larger packets >unless this is administratively configured OR the neighbor >discovery / >jumbo ARP probing takes place. > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
