Subject: Re: new I-D - DHCP solution

From: "S. Daniel Park" <[email-masked]>
Date: Sat, 17 Apr 2004 01:05:49 +0900

Jordi, this draft is very interesting and here are some comments on this.

As you cited in this draft, I already proposed a DHCP solution
to provide IPv6-over-IPv4 tunnel service on the dual host.
In Scenarios, I think DHCP can satisfy their needs simply
for example: finding a nearest tunnel and load balancing, with
simple extensions (e.g., configured tunnel end-point option,
nearest TB address option and so on...). Regarding load balancing,
DHCP already had it on the server side.

Typically, we live near the DHCP servers not just one
location and if they provide available tunnel end-points (or TB)
in their local area, all host will make use of the best tunnel service.
Of course, all host must have this function.

After very very roughly reading it, I feel this draft has a bias
toward anycast solution. Is it your intentional approach or
anything else ?

I will let you know more comments after looking into it.

Regards.

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, Samsung Electronics.

----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 16, 2004 11:05 PM
Subject: new I-D

Hi,

As part of the work that we are doing, as already indicated by Pekka a few
weeks ago, we sent yesterday a 1st version of the "Evaluation of v6ops
Auto-discovery for Tunneling Mechanisms".

For the impatiens, we have uploaded it at
http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-tun-auto-disc-00.txt.

Please, let's know your inputs so we can update it quickly, as we will like
to submit at least a new version before next meeting.

Regards,
Jordi

**********************************
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.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 16 Apr 2004 18:40:34 +0200

Hi Daniel,

Thanks for your comments. I will work on your inputs about the DHCP in the next release.

I must recognize that we went more in-deep in the anycast one because we believe it could be the best, but we didn't want to discard others, and indeed will be very happy to have some contributors in the other possibilities to produce a non-biased document.

The other reason is also because anycast is already in use for 6to4, and the ideal solution will be one that is valid for 6to4, TB, TS, Teredo, may be ISATAP, and other mechanism. At this was we can have a single host supporting several transition mechanism, acting as the Tunnel End Point for all of them (I call this simply TS, Tunnel Server, to simplify), and probably making easier the transition because we will need to deploy less boxes with more functionalities and at the same time offering more solutions that facilitate somehow the interworking of clients using different mechanisms.

As you say, DHCP is a very good one, but requires updating the DHCP client to support the new option, and may be this is less practical, but I must say this is a quick thought and we need to go further to make a balanced decision. Also remember that not always we are using DHCP, and for example, the DHCP server at the ISP might provide it to the customers, but in the IPv4 world, 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).

I will be happy to heard new inputs from your side when you have some more time.

Regards,
Jordi

----- Original Message ----- 
From: "S. Daniel Park" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>; <[email-masked]>
Cc: "???" <[email-masked]>
Sent: Friday, April 16, 2004 6:05 PM
Subject: Re: new I-D - DHCP solution

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: Pekka Savola <[email-masked]>
Date: Sun, 18 Apr 2004 11:30:42 +0300 (EEST)

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

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 20 Apr 2004 18:01:50 -0700

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