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
pgpRExUg6XyBz.pgp
Description: PGP signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
