Subject: [dhcwg] Fwd: [Softwires] I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt

From: Ole Troan <[email-masked]>
Date: Wed, 3 Feb 2010 16:59:52 +0100

hi,

we've just posted an updated revision of the 6rd draft, which we
believe is ready for last call in the softwires and dhc working
groupsl.

apart from cleaning up text the main changes are in the DHCP option,
which now includes a list of BR IPv4 addresses. (I misread RFC3396 to
allow for multiple DHCP options as a way of doing this, unfortunately
not so with the format we had. thanks to the dhc wg expers for
correcting me.)

we have also taken out all deployment considerations which were in the
revision 03 draft. if anyone is interested in taking that work up, it
could be a separate draft in v6ops.

the complete diff-set is available here:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ipv6-6rd-04.txt

Best regards,
Ole

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Wed, Feb 3, 2010 at 4:45 PM
Subject: [Softwires] I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires Working Group of the IETF.

       Title           : IPv6 via IPv4 Service Provider Networks "6rd"
       Author(s)       : M. Townsley, O. Troan
       Filename        : draft-ietf-softwire-ipv6-6rd-04.txt
       Pages           : 16
       Date            : 2010-02-03

This document specifies an automatic tunneling mechanism tailored to
advance deployment of IPv6 to end users via a Service Provider's IPv4
network infrastructure.  Key aspects include automatic IPv6 prefix
delegation to sites, stateless operation, simple provisioning, and
service which is equivalent to native IPv6 at the sites which are
served by the mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Rémi Després <[email-masked]>
Date: Wed, 3 Feb 2010 17:54:19 +0100

Ole,

I just noted that the reference to RFC 5569, that Mark noted when I last met with him, has been missed in the first sentence, and in the acknowledgements section.

The sentence he had agreed on was:

"The original idea and the name of the mechanism (6rd) specified in this document is described in [RFC 5569], a recommended background reading which details a successful commercial "rapid deployment" of the 6rd.

Is it possible to have this sentence back in?

Nothing else noted (at least after a first glance).

Best regards,

RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 3 Feb 2010 18:14:11 +0100

Remi,

> Nothing else noted (at least after a first glance).

RFC5569 isn't available in the xml2rfc reference library yet. the correct reference will be added as soon as that occurs.

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 3 Feb 2010 22:04:39 +0100

Remi,

> Nothing else noted (at least after a first glance).

RFC5569 isn't available in the xml2rfc reference library yet. it wil

---

From: Ole Troan <[email-masked]>
Date: Thu, 4 Feb 2010 10:22:38 +0100

Santhosh,

> I suggest below information can be added for more clarity and extension of existing draft.
> 
> 1) We are considering Service Provider gateway (6RD gateway) should directly connected to IPv6 internet. In this case, using ISATAP also we can achieve same.
> [Better to mention analysis on ISATAP comparision in specified scenario]
> 
> 2) Handling in case of 6RD gateway is not connected with IPv6 internet (another tunnel can be required in this case, may be manual). 

you are correct that the BR can connect to the IPv6 internet using any existing mechanism including tunneling. this shouldn't have any effect on the 6rd mechanism itself I think, so this might better belong to an operational or deployment draft?

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 4 Feb 2010 12:53:06 +0100

Santosh,

> We are considering Service Provider gateway (6RD gateway) should directly connected to IPv6 internet.
> [In this case, using ISATAP also we can achieve same]
> 
> If SP gateway is not directly connected to IPv6 internet (when we are using ISATAP), we can use ISATAP with manual tunnel.
> I want to point out comparision between 6RD and ISATAP applicability.

you can of course connect the 6rd BR to the IPv6 Internet any way imaginable just as you can with an ISATAP router.

> Is there any deployment advantages in 6RD over ISATAP ? (Please clarify)

ISATAP (and 6over4) are tunnel mechanisms which create a virtual Ethernet connecting isolated hosts.

6rd (and 6to4) are tunnel mechanisms which allow isolated _sites_ to connect to each other.

one is within an organisation, the other is between organisations.

6rd implicitly does prefix delegation. ISATAP does SLAAC as a part of a shared /64.

very different deployment scenarios. (of course where things start to blend together is if you chose to use one of them just for transport, e.g ISATAP or 6to4 and then used DHCP PD on top of that, with native prefixes.)

Best regards,
Ole

---

From: SanthoshReddyY 71702 <[email-masked]>
Date: Thu, 04 Feb 2010 12:30:41 +0800

Dear Troan,

Thanks and Regards
Santhosh

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Ole Troan <[email-masked]>
Date: Thursday, February 4, 2010 0:00 am
Subject: [Softwires] Fwd:  I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt
To: [email-masked], [email-masked]

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.This draft is a work item of the Softwires Working 
> Group of the IETF.
> 
>

---

From: SanthoshReddyY 71702 <[email-masked]>
Date: Thu, 04 Feb 2010 19:08:06 +0800

Dear Troan,

Thank you for quick reply.

Thanks and Regards
Santhosh

----- Original Message -----
From: Ole Troan <[email-masked]>
Date: Thursday, February 4, 2010 5:38 pm
Subject: Re: [Softwires] Fwd:  I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt
To: SanthoshReddyY 71702 <[email-masked]>
Cc: [email-masked], [email-masked]

> > 1) We are considering Service Provider gateway (6RD gateway) 
> should directly connected to IPv6 internet. In this case, using 
> ISATAP also we can achieve same.
> > [Better to mention analysis on ISATAP comparision in specified 
> scenario]> 
> > 2) Handling in case of 6RD gateway is not connected with IPv6 
> internet (another tunnel can be required in this case, may be 
> manual). 
> 
> you are correct that the BR can connect to the IPv6 internet using 
> any existing mechanism including tunneling. this shouldn't have 
> any effect on the 6rd mechanism itself I think, so this might 
> better belong to an operational or deployment draft?
> 
> cheers,
> Ole
>

---

From: SanthoshReddyY 71702 <[email-masked]>
Date: Thu, 04 Feb 2010 20:09:08 +0800

Dear Troan,

Thank you.

Thanks and Regards
Santhosh

----- Original Message -----
From: Ole Troan <[email-masked]>
Date: Thursday, February 4, 2010 7:53 pm
Subject: Re: [Softwires] Fwd:  I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt
To: SanthoshReddyY 71702 <[email-masked]>
Cc: [email-masked], [email-masked]

> > If SP gateway is not directly connected to IPv6 internet (when we 
> are using ISATAP), we can use ISATAP with manual tunnel.
> you can of course connect the 6rd BR to the IPv6 Internet any way 
> imaginable just as you can with an ISATAP router.
> 
> very different deployment scenarios. (of course where things start 
> to blend together is if you chose to use one of them just for 
> transport, e.g ISATAP or 6to4 and then used DHCP PD on top of that, 
> with native prefixes.)
> 
> Best regards,
> Ole
> 
>

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 4 Feb 2010 22:40:35 +0900

Hi Ole-san,

I have a question about MTU option in router advertisement.
The draft says:

> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined
> automatically or configured directly, on the LAN side by setting the
> MTU option in Router Advertisements [RFC4861] messages to the 6rd
>  Tunnel MTU."

My understanding of the role of MTU option in RA is that if hosts are in
configuration in which different media type are bridged, advertising mtu size
all media supported.

Does CPE should advertise the 6rd Tunnel MTU even 6rd tunnel does not bridged 
to CPE LAN side?

--satoru

---

From: Ole Troan <[email-masked]>
Date: Thu, 4 Feb 2010 15:28:11 +0100

Matsushima-san,

> Does CPE should advertise the 6rd Tunnel MTU even 6rd tunnel does not bridged 

if you are thinking of the text in RFC4861 I read that as an _example_ of a case where the MTU option could be used. do you see any problems with recommending to match the LAN-side MTU with the WAN-side MTU? assuming we cannot get to something like SEAL in time (RFC5320).

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 4 Feb 2010 15:28:42 +0100

Matsushima-san,

> Does CPE should advertise the 6rd Tunnel MTU even 6rd tunnel does not bridged 

if you are thinking of the text in RFC4861 I read that as an _example_ of a case where the MTU option could be used. do you see any problems with recommending to match the LAN-side MTU with the WAN-side MTU? assuming we cannot get to something like SEAL in time (RFC5320)

Best regards,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 4 Feb 2010 15:39:09 +0100

>>> MTU option in Router Advertisements [RFC4861] messages to the 6rd

May I suggest a slightly different wording which might cover Satoru's concern:

If A 6rd CE advertises an MTU on the LAN (by setting the MTU option in Router Advertisements [RFC4861], it SHOULD do it with 6rd Tunnel MTU, whether determined automatically or configured directly.

RD

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 5 Feb 2010 20:16:31 +0900

Ole-san,

> if you are thinking of the text in RFC4861 I read that as an _example_ of a case where the MTU option could be used. do you see any problems with recommending to match the LAN-side MTU with the WAN…

No, I just surprised by this specification which matching the LAN side MTU size with the WAN side MTU size.
Is this generic way even CPE can response to host with "packet too big" message?
If it is generic, why  not in BR side?

--satoru

---

From: Ole Troan <[email-masked]>
Date: Fri, 5 Feb 2010 12:17:47 +0100

Satoru-san,

> If it is generic, why  not in BR side?

it is expected that path MTU discovery works in the IPv6 Internet (sic!). there isn't much one can do with the native IPv6 side MTU on the BR in any case. of course the BR tunnel MTU has to be managed as described.

cheers,
Ole

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 5 Feb 2010 20:23:26 +0900

Remi-san,

> May I suggest a slightly different wording which might cover Satoru's concern:

Your wording will mitigate my feeling.

Thanks,

--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 5 Feb 2010 20:43:46 +0900

Ole-san,

> it is expected that path MTU discovery works in the IPv6 Internet (sic!)

The purpose of this specification is for avoiding PMTU at least the LAN side hosts of 6rd CPE.
Is this correct?

Regards,

--satoru

---

From: Ole Troan <[email-masked]>
Date: Fri, 5 Feb 2010 13:12:19 +0100

> The purpose of this specification is for avoiding PMTU at least the LAN side hosts of 6rd CPE.

that's correct.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2010 15:04:44 -0800

Hi,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Friday, February 05, 2010 4:12 AM
> To: Satoru Matsushima
> Cc: [email-masked]; [email-masked]

Regarding the 6rd MTU, I am going to replay a post I
just made on softwire wrt to a related issue:

http://www.ietf.org/mail-archive/web/softwires/current/msg01186.html

I will make a very few minor revisions to the text in
terms of 6rd below to show that the two cases (and their
respective implications for MTU determination) are really
one and the same::

Begin replayed post (with minor rewording for 6rd):
***************************************************
Setting a reduced MTU on the 6rd CE router LAN interface
seems like a safe option at face value, but can lead to
undesirable inefficiencies. Consider for example the
diagram below:

            L1    L2               
            |     |                
        W --|--R--|--CE1======BR2-- <   IPv6   > --Z
            |     |  (ISP Network)  < Internet >
               X--|     L4, L5,
               Y--|     L6, etc.

Here, we have a tunnel between 'CE1' and 'BR2' over the
ISP network to the IPv6 Internet. 'CE1' sets a reduced
MTU 'M' on its LAN interface connected to link 'L2', and
also advertises 'M' in the Router Advertisements it sends
on 'L2'. Hosts 'X' and 'Y' pick up the reduced MTU from
the RA and limit the size of the packets they send to at
most 'M' bytes. But, host 'W' connected to link 'L1' does
not see the MTU reduction, and hence will routinely send
packets larger than 'M' to any hosts beyond router 'R'
such as 'X', 'Y' and 'Z'. These packets will be dropped
with an ICMPv6 PTB returned, then 'W' will be forced to
reduce its packet size and retransmit. The only way to
prevent this is to drive the reduced MTU 'M' deeply into
the entire network stacked up behind 'CE1', which may
contain arbitrarily many additional routers and links.

Now, even if the reduced MTU 'M' were propagated deeply
throughout the 'CE1' network, if most communications
remain localized hosts would only be able to use a packet
size of at most 'M' even if their links natively support
a much larger MTU. Consider for example that link 'L2'
in the diagram has a native MTU of 9kb, but the effective
MTU across the 'CE1'===='BR2' tunnel is only 1400. 'CE1'
will advertise 1400 on link 'L2', and communications
between hosts 'X' and 'Y' will be restricted to using at
most 1400 byte packets when they could have used 9kb.

There are a couple of factors to consider in terms of
what might be a better solution. First, what are the
expected data rates over the 'CE1'===='BR2' tunnel,
and second what are the performance characteristics of
those gateways? If the data rates are such that GW1 and
GW2 are already operating at their peak performance even
without taking on any additional processing overhead,
then the best solution would be to make sure that all
links over which the tunnel might travel (e.g., 'L4',
'L5', 'L6', etc.) are large enough to "hide" the tunnel
encapsulation artifact. For example, if all links 'L4'
'L5', 'L6', etc. configure a native MTU of no smaller
than 1600 and the encapsulation overhead for the tunnel
is 100 bytes, then all routers and hosts on the LAN side
of 'CE1' would be able to happily use a 1500 MTU. If the
MTUs of 'L4', etc. cannot be controlled, however, then
there is no recourse but to set the reduced MTU on the
CE1 LAN interface and cope with the inefficiencies.

On the other hand, if the data rates across the tunnel
are nominal and/or 'CE1' and 'BR2' have more than
sufficient processing capability to take on a modest
amount of additional overhead, the tunnel can use tunnel
fragmentation so that 'CE1' can present a solid MTU on
its LAN side interface that does not reflect the size
of the tunnel encapsulation headers. If the tunnel
fragmentation could accommodate an MTU of at least 1500
in this way, then 'CE1' would be able to observe the
"de facto Internet cell size" of 1500. If we further
assume that the vast majority of hosts in the world
today either limit their packet sizes to no more than
1500 bytes or are willing to assume the risk of silent
loss of packets larger than 1500 due to MTU restrictions,
then there is no need to place artificial restrictions
on the size of packets that can be used within the 'CE1'
network. This latter class of hosts (those that send
packets larger than 1500) would be best served to use
their own host-based MTU probing mechanisms for sending 
packets larger than 1500 in case the network is somehow
silently dropping PMTUD messages. RFC4821 was specifically
designed for this purpose.

End result - whenever it is practically possible, tunnel
routers such as CE1 and BR2 should use tunnel fragmentation
and hosts should use RFC4821.

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 5 Feb 2010 15:23:09 -0800

Hi Ole,

> Sent: Thursday, February 04, 2010 3:53 AM
> To: SanthoshReddyY 71702
> very different deployment scenarios. (of course where things start to blend together is if you chose
> to use one of them just for transport, e.g ISATAP or 6to4 and then used DHCP PD on top of that, with
> native prefixes.)

You are talking here only about the "letter of the law"
of RFC5214. But, the applicability statement also says:

   "Extensions to the above domain of applicability (e.g., by combining
   the mechanisms in this document with those in other technical
   specifications) are out of the scope of this document."

Those "extensions" have been in the works since before
RFC5214 (and indeed even its predecessor RFC4214) were
published. The extensions are now culminating in a
specification known as VET, which extends the "basic"
ISATAP functionality by also allowing for router-to-
router tunneling. That makes VET a candidate for the
ISP scenario use case the same as for 6rd, where VET
can use either DHCP PD or PI delegated prefixes. But
if there is sufficient interest, VET can also be easily
extended to support the stateless PD feature of 6rd.

Thanks - Fred