Subject: [Softwires] comments on problem statement

From: Laurent Toutain <[email-masked]>
Date: Mon, 26 Dec 2005 11:33:53 +0100

Hi,

Here are my comments based on the v4.txt document

Introduction : 3rd § change Hub and Spoke section 4 to section 3
idem for section 5 => section 4

Section 3 : Hub and Spoke

  3.4 :
Last § : Similarly, in the case of an IPv4 softwire, the address  
could be
    provided by means of DHCP.

=>Our implementation uses ND, we can also use only link local  
addresses, Global addresses
on the tunnel are just given for management reasons (traceroute, or  
if the provider or others wants
to access the HGWv6, if it is just for forwarding link local is enough).

3.5:
may be add after "Nomadicity should be supported.", as well as  
renumbering of the IPv4 address by
the provider.

I don't know if it is common in other countries, by my provider  
change my IPv4 address every day, so the
Softwire Initiator has to reestablish a tunnel just after the  
renumbering.

3.6:

This is my main concern regarding this draft. It focus to much, in my  
point of view to the tunnel establishment"

This section could emphase more on interaction between different  
protocols (ND, DHCPv6, AAA,...) In our
experiences that was the most difficult part. May be we have to  
recommend the usage of some  options in this
protocols or ask for new types (for instance delegated prefixes in  
Radius is a draft). Section 3.11 talks about
AAA by in very generic way. In my view AAA is the most important  
feature for softwire, because it will contains
a lot of information that will help the provider to manage the  
network (prefix for the customer, DNS, domains,..)
that are very useful for a home IPv6 network.

3.13

I'm surprised not to see listed IPv4/UDP/L2TP/PPP/IPv6

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Dec 2005 23:09:07 +0100

Hi Laurent,

See my comments below, in-line (ok when nothing replied).

Regards,
Jordi

De: Laurent Toutain <[email-masked]>
Responder a: <[email-masked]>
Fecha: Mon, 26 Dec 2005 11:33:53 +0100
Para: "[email-masked]" <[email-masked]>
Asunto: [Softwires] comments on problem statement

Hi,

 3.4 :
Last § : Similarly, in the case of an IPv4 softwire, the address could be
   provided by means of DHCP.

=>Our implementation uses ND, we can also use only link local addresses,
Global addresses
on the tunnel are just given for management reasons (traceroute, or if the
provider or others wants
to access the HGWv6, if it is just for forwarding link local is enough).

[Jordi] I also have my doubts here. I agree that may be requiring DHCP is
too much. We may rely in two choices may be.

3.5: 
may be add after "Nomadicity should be supported.", as well as renumbering
of the IPv4 address by
the provider. 

I don't know if it is common in other countries, by my provider change my
IPv4 address every day, so the 
Softwire Initiator has to reestablish a tunnel just after the renumbering.

[Jordi] Agree, but it can be managed in an alternative way. Example, when
the tunnel is dropped (IPv4 address get changed), softwire must be
re-initiated. It may be much simpler and efficient, unless you¹ve an
alternative suggestion to keep it easy ?

3.6:

This is my main concern regarding this draft. It focus to much, in my point
of view to the tunnel establishment"

This section could emphase more on interaction between different protocols
(ND, DHCPv6, AAA,...) In our 
experiences that was the most difficult part. May be we have to recommend
the usage of some  options in this
protocols or ask for new types (for instance delegated prefixes in Radius is
a draft). Section 3.11 talks about 
AAA by in very generic way. In my view AAA is the most important feature for
softwire, because it will contains
a lot of information that will help the provider to manage the network
(prefix for the customer, DNS, domains,..)
that are very useful for a home IPv6 network.

[Jordi] The idea was to rely as much as possible in existing protocols (such
as DHCPv6) and also agree that this is very important because even can help
to keep the same tunnel (for an IPv6 one) if the IPv4 address change,
because the user information seems to be the only way to associate both ...
Again concrete inputs here are welcome !

3.13

[Jordi] Again the idea here is to keep it simple. Other choices may be
supported, but it seems that those that we have as mainstream are enough to
cover every scenario (with/without NAT).

Laurent

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 28 Dec 2005 16:04:38 +0100

Le 27 déc. 05 à 23:09, JORDI PALET MARTINEZ a écrit :
> [Jordi] Agree, but it can be managed in an alternative way.  
> Example, when the tunnel is dropped (IPv4 address get changed),  
> softwire must be re-initiated. It may be much simpler and  
> efficient, unless you’ve an alternative suggestion to keep it easy ?

No but one requirement could be to detect the change quickly (even  
behind a NAT) and the renegociation gives the same result.

>
>
> 3.6:
>
> This is my main concern regarding this draft. It focus to much, in  
> my point of view to the tunnel establishment"
>
> [Jordi] The idea was to rely as much as possible in existing  
> protocols (such as DHCPv6) and also agree that this is very  
> important because even can help to keep the same tunnel (for an  
> IPv6 one) if the IPv4 address change, because the user information  
> seems to be the only way to associate both ... Again concrete  
> inputs here are welcome !
>
We have concrete inputs regarding our implementation. I can send  
implementation details but we are discussing the framework.
BTW if you want to survive IPv4 renumbering, it means that you need  
authentication.

> [Jordi] Again the idea here is to keep it simple. Other choices may  
> be supported, but it seems that those that we have as mainstream  
> are enough to cover every scenario (with/without NAT).

L2TP is in fact very simple for many reasons :

it use UDP, so it is NAT traversal
it use PPP, so it is very common in telco architecture and very well  
interfaced with Radius
                           it has a very good way to authenticate  
users with challenges
                           it gives Link Local addresses to both ends
                           it can detect when a tunnel is broken

the only drawback is the header UDP/L2TP/PPP encapsulation is 18  
Bytes, but who cares regarding
all the good properties it introduces.

Laurent

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 30 Dec 2005 10:10:46 +0100

Hi Laurent,

See below.

Regards,
Jordi

De: Laurent Toutain <[email-masked]>
Responder a: <[email-masked]>
Fecha: Wed, 28 Dec 2005 16:04:38 +0100
Para: "[email-masked]" <[email-masked]>
Asunto: Re: [Softwires] comments on problem statement

Le 27 déc. 05 à 23:09, JORDI PALET MARTINEZ a écrit :
> 
>  3.5: 
>  may be add after "Nomadicity should be supported.", as well as renumbering of
> the IPv4 address by
>  the provider. 
>  
>  [Jordi] Agree, but it can be managed in an alternative way. Example, when the
> tunnel is dropped (IPv4 address get changed), softwire must be re-initiated.
> It may be much simpler and efficient, unless you¹ve an alternative suggestion
> to keep it easy ?

No but one requirement could be to detect the change quickly (even behind a
NAT) and the renegociation gives the same result.

[Jordi] I think is there already, when talking about keepalives, we may need
to make it more clear.
>  experiences that was the most difficult part. May be we have to recommend the
> usage of some  options in this
> as DHCPv6) and also agree that this is very important because even can help to
> keep the same tunnel (for an IPv6 one) if the IPv4 address change, because the
> user information seems to be the only way to associate both ... Again concrete

[Jordi] Well, if you have an implementation, you have probably already
though before on the requirements, so you can look back behind your existing
implementation ... And yes, agree on the authentication.

                          it has a very good way to authenticate users with
challenges

the only drawback is the header UDP/L2TP/PPP encapsulation is 18 Bytes, but
who cares regarding
all the good properties it introduces. 

[Jordi] Confused here. In IPv6 we don¹t have NAT, so you don¹t need to use
else just IPv4/IPv6, right ? We are talking here about when you have only
IPv6 in the access/core network and want to make usage of IPv4 from the LAN.
Now if we are talking about IPv6 being used in an IPv4-only access/core
network, then yes, PPP or L2TP are good choices, but the point here is what
is the advantage of them if you can use already just UDP ? The idea here is
to require a minimum set of encapsulation protocols, not all of them that
you can actually use. So after we define the protocol, any implementation
will need to support the minimum set, and is free to use others in addition.
My experience while traveling is that some times you can¹t use VPNs with
L2TP neither PPP (in many hotel hot spots), so I don¹t see the difference if
trying to use just UDP, but may be I¹m missing something.

Laurent