Re: new I-D - DHCP solution

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 16 Apr 2004, JORDI PALET MARTINEZ wrote:
> [...] most of the customer
> networks have their own NAT box, with their own DHCP server, that
> not necessarily is reading (and getting updated) the ISP DHCP server
> info (and if this is the case, this router should be also upgraded
> to support the new DHCP option).

Was this stated clearly enough?  This is probably a very good point 
that needs to be stated clearly.

Either the DHCP server at the NAT box would have to propagate the 
option, or the NAT box would have to support IPv6 to create the tunnel 
on its own.

...

A bit of brainstorming of my own; compared to anycast, DHCP seems to
have a few tradeoffs:

pro-DHCP:
 + it would only be used when there _is_ guaranteed service, i.e., one 
would not have to send the packets to anycast address if there is no 
service (whether this is a concern depends on how anycast discovery 
would be done, see specific issues w/ anycast below).
 + DHCP for configuration parameters is a technique for v4 which we're 
familiar with already (for the good and bad).

pro-anycast:
 + works also when the provider's DHCP info is not propagated to the
ultimate user (e.g., due to NAT box)
 + does not require any implementation which couldn't be done in the 
tunnel server system itself, either at DHCP server or DHCP 
client software; i.e., no 3rd party dependencies, which is pretty 
important
 + can be reasonably constrained if combined with a DNS lookup, and 
anycasting the result. (compare to the discovery mechanism for 
ISATAP.)

specific issues in anycast which need to be addressed:
 * it may be undesirable to allocate an interdomain anycast prefix ala 
6to4 for this purpose due to a number of reasons, e.g.:
  - when there is no service to be offered at all, the search may take 
long to terminate, especially if you don't get back 
network-unreachable.
  - there is far less incentive for 3rd parties to provide service 
than with 6to4 relays, so the chances of finding a willing tunnel 
server with interdomain anycast is pretty slim.
  - when you move between domains, it might still be easiest if you 
were able to use your "home ISP's server".  The ISP could be blocking 
that, of course, but esp. if you're authenticated, it should still 
work.

 * if naycast is not an assigned interdomain anycast prefix, it needs
to be discovered somehow.  DNS lookup is a strong candidate, but there
are devils in the details.  This could be a simple "A" query for e.g.,
tunnel-server.<search-path>, NAPTR query (two roundtrips, extra
implementation), or whatever.  This would be easily configured
manually as well.  That would have to be figured out.

 * when the user moves from an ISP's network to another (e.g., due to 
mobility/roaming), there needs to be some process that notices this 
change.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings