[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new I-D - DHCP solution
Hi Pekka,
Thanks for your comments we will take them in consideration for the next review for the document.
Will also make sure that the DHCP cons are clear enough, same as the anycast issues.
It will be very good to have other people looking at this document before we issue a new version.
Regards,
Jordi
----- Original Message -----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Sunday, April 18, 2004 1:30 AM
Subject: Re: new I-D - DHCP solution
> 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
>
>
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line 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.