Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Nov 2003 09:09:45 -0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dave Thaler
> Sent: lundi 24 novembre 2003 19:30
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt
> 
> This is the issue I mentioned again in Minneapolis...
> 
> From draft-ietf-v6ops-mech-v2-01.txt:
> >
> > 3.2.1.  Static Tunnel MTU
> >
> >    A node using a static tunnel MTU MUST limit the size of the IPv6
> >    packets it tunnels to 1280 bytes i.e., treat the tunnel interface
> as
> >    having a fixed interface MTU of 1280 bytes.  An implementation
MAY
> >    have a configuration knob which can be used to set a larger value
> of
> >    the tunnel MTU than 1280 bytes, but if so the default MUST be
1280
> >    bytes.  A larger fixed MTU should not be configured unless it has
> >    been administratively ensured that the decapsulator can
reassemble
> >    packets of that size.  Care should be taken when manually
> configuring
> >    large tunnel MTUs to only do so when the MTU of the IPv4 path to
> the
> >    tunnel endpoint is large to avoid causing excessive
fragmentation.
> 
> Here's a scenario which may become common:
> 
> A mobile node has
> 1) an Ethernet interface connected to a v4-only network
> 2) some type of IPv6 over IPv4 tunnel that follows this spec,
>     where the IPv4 address used for encapsulation is the address
>     on interface 1.
> 3) an IPv6 over IPv6 tunnel to its home agent to support mobile IPv6,
>     where the IPv6 address used for encapsulation (i.e. its
> care-of-address)
>     is the IPv6 address on interface 2.  With route optimization
> optional,
>     one common case is where the majority of communication would be
over
> 
>     this interface (reverse tunneled).
> 

Hi Dave:

On the side of this discussion, note that it would be beneficial to
MIPv6 to consider IPv4 traversal in order to save the intermediate
tunnel. It's very unclear where this discussion should take place. I
proposed to Nemo a year ago, and the WG said it was a MIPv6 problem. I
asked P2P to some MIPv6 members, who answered to me it was more likely
to be a v6Ops problem.

What do you think?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Nov 2003 09:26:28 -0000

Itojun:

The example that Dave proposed, a MIPv6 (Nemo) router, has exactly that
behavior when not at Home: It acts as a Host at ND level on the roaming
interface to discover an attachment router and to autoconf a CareOf. 

This gives you at least one case where it's an interesting thing to do.

Fred: in our initial implementation, we've been through this but tried
to save in the IPv6inv4 tunnel, using some automatic tunneling based on
6to4. In that case, there's no tunnel to send RS over.

What we did fits with what Dave suggested (if I understand correctly).
Rely on a correct IPv4 or IPv6 administrative MTU, and send PMTU ICMPs
back based on RFC 2473.

For more details about how that works (but nothing much about MTU since
its RFC 2473) you may want to have a look at Doors (but I know Pekka
won't). Goes through all sorts of PAT/NATs.
http://www.ietf.org/internet-drafts/draft-thubert-nemo-ipv4-traversal-01
.txt

Pascal

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jun-ichiro
> itojun Hagino
> Sent: mardi 25 novembre 2003 02:11
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: NOTE: WG Last Call: draft-ietf-v6ops-mech-v2-01.txt
> 
> > Nodes may act as hosts on some interfaces and routers on other
> > interfaces. They may also act in different turns as routers and
hosts
> > on the same interface. I see nothing in RFC 2461 that precludes such
> > "hybrid" nodes from sending RSs and processing RAs.
> >
> > In fact, the second-to-last paragraph of RFC 2461, section 6.2.7
> > ("Router Advertisement Consistency") says:
> >
> >    "Note that it is not an error for different routers to advertise
> >    different sets of prefixes.  Also, some routers might leave some
> >    fields as unspecified, i.e., with the value zero, while other
routers
> >    specify values.  The logging of errors SHOULD be restricted to
> >    conflicting information that causes hosts to switch from one
value to
> >    another with each received advertisement."
> >
> >
> > So, if router A has good reason to believe that router B advertises
> > a different set of prefixes, I see nothing unusual about A sending
> > RSs to B (and getting RAs back from B) to discover the different
> > prefixes.
> 
> 	i guess i mentioned it in the past, if we allow routers to
advertise
> 	different set of prefixes (which is the case now with RFC2462)
and
> 	allow routers to autoconfigure themselves with RA, we go into
> 	bootstraap problem when router reboots.  i consider
autoconfiguring
> 	router is a dangerous idea, and "hybrid router" idea is too.
> 
> itojun