Subject: [Softwires] Softwires configuration via DHCP

From: "David W. Hankins" <[email-masked]>
Date: Tue, 17 Feb 2009 15:02:33 -0800

In forming the DHCPv6 option format for Softwires configuration, I
made a few assumptions.  I would like to (hopefully _very_ briefly)
explain my rationale, and invite additional feedback before I revise
the draft.

1) That the only configuration required would be the endpoint - that
   the 'Softwires Protocol' would include as specification a single
   kind of tunnel, for example.  The presumption, for simplicity, is
   that any Softwire client can establish a connection with any
   Softwire service without needing to know "which type."  Put another
   way, all Softwire services will be externally identical.

2) That only a single endpoint is sensible.  That there wouldn't be
   a configuration where a client had multiple Softwire endpoints
   configured at once (migrated from one to another, but never
   straddling two or more at once).

3) That although many current tunneling software implementations might
   accept domain names as configuration parameters,

	a) A recursive domain name lookup after completing DHCP is
	   extra work for no benefit.  DHCP servers can and will
	   perform the lookup on behalf of the client.  These extra
	   packet exchanges are trivial, until every packet you transmit
	   drains your phone's battery.

	b) Tunneling is a "routing kind of service", and so my first
	   inclination is that operators are likely to solve tunnel
	   endpoint reachability problems ("failure modes") by using
	   classic IP routing solutions.  Consequently the
	   configuration of interest is an IPv6 address, whose
	   termination may change through changes in routing policy.

These are essentially the assumptions that went into
draft-dhankins-softwire-tunnel-option-01.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Feb 2009 15:45:45 +1300

David,

On 2009-02-18 12:02, David W. Hankins wrote:
...
>    straddling two or more at once).

Wouldn't you want a short overlap to allow seamless migration
of application sessions? Break-before-make is not good for
real time streams or for any kind of QOS assurance.

   Brian

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 17 Feb 2009 20:20:19 -0800

> real time streams or for any kind of QOS assurance.

I think two Softwires endpoints will cover different IPv4 address
ranges on the 'external' side of the CGN.  So even make-before-break
would not provide what you are looking for?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 11:04:28 +1300

> would not provide what you are looking for?

Actually, wouldn't it allow a clever NAT to update session state
automatically? In any case, we can't be sure that this is the only
usage scenario for ever.

   Brian

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 18 Feb 2009 14:27:58 -0800

First, thank you Brian for responding and thinking about this, I do
appreciate it.  My writing style is sometimes dry.

On Thu, Feb 19, 2009 at 11:04:28AM +1300, Brian E Carpenter wrote:
> automatically?

If you were to have two nodes sharing NAT mapping state, why would you
prefer to wait for DHCP renewal timers rather than to have the
surviving CGN simply take over routing for its peer's /128?  This is
the area of solutions I mean when I say I would expect 'tunnels' to
be handled by routing equipment, and solved with classic routing
solutions.

Surely by the time you are coordinating such NAT tables, the idea of
coordinating the use of /128s (fallbacks, anycasts) is trivial, and
preferrable to placing complications on the softwire-client end?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2009 13:22:25 +1300

David,

> appreciate it.  My writing style is sometimes dry.

This is the IETF, isn't it? ;-) Dry is fine...

> preferrable to placing complications on the softwire-client end?

I won't argue with you for the currently envisaged scenarios. I've
been looking at things with slightly different eyes while working
on draft-carpenter-renum-needs-work, because there seem to be quite
a lot of existing mechanisms that could be repurposed to support
dynamic renumbering, and there make-before-break has benefits.

    Brian