Subject: IPv6 Tunnel End-point Automatic Discovery Mechanism

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 6 Sep 2004 04:23:57 +0200

Hi,

We have submitted a new document. It can be already read at:

http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-solution-tun-auto-disc-00.txt

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: "S. Daniel Park" <[email-masked]>
Date: Tue, 07 Sep 2004 16:55:12 +0900

Hi Jordi, thanks your effort on this work.

Basically, you have to use a new boilerplate for this draft.
In this draft, several abbreviations (i.e., TEP, TS, TEB...)
are shown without any terminology description, so I 
recommend you to simply address them if possible.

My major comment is as below;

In Abstract;

>This memo proposes a solution for discovering the IPv6 TEP
>in a simple an efficient way.

Isn't the IPv4 TEP correct ? (if you mean tunnel described in
this draft is the IPv6-over-IPv4 tunnel). IPv6-over-IPv4 tunnel where
the IPv4 tunnel endpoint address is learned from the solutions
proposed in this draft. If you mean IPv6 TEP is only *endpoint*
from the IPv6 aspect, you should at lease address this assumption
and indicate the difference between TEP and TEP address.
For example: TEP address is a destination address of IPv4
encapsulating IPv6 packets where IPv6-over-IPv4 tunnel is the
technique of encapsulating IPv6 packets within IPv4 is used
to accross IPv4 routing infrastructures.

Thanks

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of JORDI PALET MARTINEZ
> Sent: Monday, September 06, 2004 11:24 AM
> To: [email-masked]
> Subject: IPv6 Tunnel End-point Automatic Discovery Mechanism
> 
> 
> Hi,
> 
> 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: Sun, 12 Sep 2004 18:55:53 +0200

Hi Daniel,

Thanks for your comments. Please see my inputs in-line below.

Regards,
Jordi

---- Original Message ----
From: "S. Daniel Park" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>;
<[email-masked]> Sent: Tuesday, September 07, 2004 9:55 AM
Subject: RE: IPv6 Tunnel End-point Automatic Discovery Mechanism

> Basically, you have to use a new boilerplate for this draft.

I'm surprised. I though that using the HTML interface of http://xml.resource.org/ the boilerplate is automatically added (the good one). May be I published the I-D right before a change ?

> recommend you to simply address them if possible.

Yes, you're right, a terminology section will be very useful.

> to accross IPv4 routing infrastructures.

I'm meaning in general any type of tunneling mechanism that uses 6in4 (proto-41), to encapsulate IPv6 in IPv4.

My view is that as we are tunneling IPv6, the tunnel end point is an IPv4 address, so then you're probably right, it should be IPv4 TEP. We can clarify this in the next version.

But actually, in the conclusions section, we have an open question mark:
Can/should we use this document also for auto-discovering IPv4 in IPv6 tunnels ?

My belief is that this mechanism is equally applicable to discover the TEP for the reverse situation, when we need to create a 4in6 tunnel.

If is the case and this is acceptable for the WG, then we need to review all the references to TEP across the text, and replace A/CNAME with A/AAAA/CNAME, etc.

My personal opinion is that this will provide a very efficient way to open the path for the next stage of the transition, using the same mechanism, instead of defining something different. It just doesn't make any sense. But I need to spend some time in looking if for example SRV and anycast will work the same.

I will much prefer to get first feedback from the WG about if this mechanism of doing the discovery is acceptable, etc.