Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual?

From: "Miguel Angel Diaz" <[email-masked]>
Date: Tue, 18 Jan 2005 10:17:03 +0100

> On Fri, 2005-01-14 at 19:49 +0100, Miguel Angel Diaz wrote:
>> Even in your case the discovery method we are going to propose will work.
> 
> Can you please explain me how it would work? Because I really can't see
> how it can because there is absolutely no information that makes you
> able to figure out the nameservers of the ISP with the information I
> gave below ;)
> 

We are going to give all the details in the new draft version, but meanwhile just think that it isn't difficult to extract the ISP domain name (at least one valid) to make the DNS queries. The only requirement is that the ISP deploys the TEP on its own network and it configures properly its autoritative DNS server.

In your case, if we assume that your ISP has different TEPs, the SRV DNS queries to discover them could be:

_teredo._udp.cistron.nl
_6to4._ipv6.cistron.nl
etc.

How to find out your ISP domain name? It is simple, just type:

dig soa -x 195.64.92.136 +noall +authority

and extract the domain from the authoritative DNS server (ns.cistron.nl)  :-)

Remember that it is necessary that ISP is in charge of setup the DNS servers that manage the cistron.nl domain with the proper entries for _teredo.udp, _6to4._ipv6, etc SRV RR. 

>>  Basically we only suppose one thing: the local ISP is the entity that deploys the TEP that the user (rather the OS) is looking for.
>>
>> With that premise we propose to use SRV RR because the advantages shown
>> in http://www.ietf.org/internet-drafts/draft-palet-v6ops-solution-tun-auto-disc-01.txt.
>> However to use effectively that approach it is necessary to know the ISP domain
>> name which is not trivial because it is not usually propagated.
> 
> That was the question I asked you, how are you going to figure out in
> which domain you need to look for those records?
> 
>> The new draft version of draft-palet-v6ops-solution-tun-auto-disc will propose a
>> method to discover not only the ISP domain name but also the DNS server to make the SRV queries.
> 
> You think that my DNS server has a relation to the DNS server of my
> upstream ISP? No way, they don't do IPv6 nor DNSSEC and mine does.
> 
>> To do that the only thing is to find out the authoritative DNS server on the ISP domain and then you'll have all.
> 
> And _how_ are you going to do it? that you want to do it is clear, but
> how? :)
> 
>> In this way the queries will be sent not to your local DNS server but the
>> authoritative DNS server of your ISP who is in charge of the TEP deployment, so it will work even in your network.
> 
> Please look again at the situation that I depicted as there really is no
> way to find out the domain name of my upstream ISP :)
> It is not even possible to do it manually unless you simply assume
> certain things, but that is done by the human brain, not by the
> computer.
> 
> Greets,
> Jeroen
> 
> 
> 
> **********************************
> 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.
> 
> 
>

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

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Alain Durand <[email-masked]>
Date: Tue, 18 Jan 2005 01:50:35 -0800

> and extract the domain from the authoritative DNS server 

Can you tell us how this will work for host behind a NAT which address 
is 192.168.1.2?

	- Alain.

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Tue, 18 Jan 2005 11:39:07 +0100

> Can you tell us how this will work for host behind a NAT which address 

of course, you first has to know your public IPv4 address ;-) It doesn't matter if you have one or more NAT levels, the only thing is to find out your final public address. There are several ways to do it and one of the most used is the STUN protocol, RFC 3489.

Other approach might be the one you pointed time ago: ISP has to public reverse DNS for the private addresses, but I guess it won't work well in networks with local DNS server like the Jeroen's case. The only effective solution that fits the most of the scenarios is to take the public address.

Regards
Miguel

---

From: Alain Durand <[email-masked]>
Date: Tue, 18 Jan 2005 03:18:33 -0800

On Jan 18, 2005, at 2:39 AM, Miguel Angel Diaz wrote:

> of course, you first has to know your public IPv4 address ;-) It 
> doesn't matter if you have one or more NAT levels, the only thing is 
> to find out your final public address. There are several ways to do it 
> and one of the most used is the STUN protocol, RFC 3489.

I was expecting this answer. Can you now tell how to discover which 
stun server to use?

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Jan 2005 12:32:58 +0100

> I was expecting this answer. Can you now tell how to discover which 

That is why I offered him the traceroute option, to at least get the
IP's and then the reverses of the ISP, not that it would be really
visible and quite hard to find out then where a) to trace to and b)
which hop actually belongs to the ISP, but still ;)

Also miguel, you really think that I did not have a special reverse on
my box? At least internally 195.64.92.136 is also nicely known as
purgatory.unfix.org and thus the SOA is also inside unfix.org, the NS
records are at purgatory.unfix.org and ns1/ns2.mediadesign.nl. Does this
lead you to cistron.nl?

I also have to note that:
 - many ISP's don't do reverse at all
 - the ISP's that usually do not use the same domain name as they
   use for their services.
 - custom reverses exist too.

Greets,
 Jeroen

/me whispers: anycast ;)

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Tue, 18 Jan 2005 12:39:09 +0100

> I was expecting this answer. Can you now tell how to discover which 

I see where you want to arrive: the stun server discovery is an issue itself, but currently there are several public stun servers deployed all over the world and they are available for free to all the users. Just some of them:
  
stun01.sipphone.com,
stun.voxgratia.org,
stun1.vovida.org,
stun.fwdnet.net,
stun.intervivo.net
 
Why don't use them?
 
 Regards
Miguel

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Jan 2005 12:01:13 +0000

> I see where you want to arrive: the stun server discovery is an issue itself, but currently there are several public stun servers deployed all over the world and they are available for free to all…

How deep a hole are we digging here? :)

Tim

---

From: Alain Durand <[email-masked]>
Date: Tue, 18 Jan 2005 04:21:32 -0800

On Jan 18, 2005, at 3:37 AM, Miguel Angel Diaz wrote:
> I see where you want to arrive: the stun server discovery is an issue 
> itself, but currently there are several public stun servers deployed 
> all over the world and they are available for free to all the users. 
> Just some of them:
>
> stun01.sipphone.com,
> stun.voxgratia.org,
> stun1.vovida.org,
> stun.fwdnet.net,
> stun.intervivo.net
>
> Why don't use them?

Simply because hardcoding names like that in implementations that need 
to be
maintained for 10-20 years is a bad thing.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Jan 2005 14:25:02 +0200 (EET)

Hi,

On Tue, 18 Jan 2005, Miguel Angel Diaz wrote:
> to find out your final public address. There are several ways to do 
> it and one of the most used is the STUN protocol, RFC 3489.

This would create a dependency on STUN (the client has is, the ISP has 
deployed it) or similar method, and would create additional 
roundtrips.  This seems unacceptable to me.

What seems left on the table from the generic solutions is an 
IPv4 anycast address.  It has some problems, but maybe these problems 
are smaller than with others.

Or, one could just state that the discovery method is not intended to 
work under every situation (e.g., forward DNS works if the NAT box 
doesn't advertise it's own domain name).  We'll see.

-- 
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: Jeroen Massar <[email-masked]>
Date: Tue, 18 Jan 2005 13:30:31 +0100

On Tue, 2005-01-18 at 04:21 -0800, Alain Durand wrote:
> >>> it

Not even mentioning the abuse of resources provided by others.

And what is the use of using a STUN in the first place, if it cannot be
reached you are dead in the water.

Greets,
 Jeroen

/me whispers some more things about anycast... ;)

---

From: Alain Durand <[email-masked]>
Date: Tue, 18 Jan 2005 05:52:30 -0800

On Jan 18, 2005, at 4:25 AM, Pekka Savola wrote:
> What seems left on the table from the generic solutions is an IPv4 
> anycast address.  It has some problems, but maybe these problems are 
> smaller than with others.

I think the discussion from the last few days has shown few things:

a) DNS based solutions (forward or reverse) do not work in all 
situations
      and in particular do not work well in the case where a NAT box is 
present,
      which seems to be a show stopper.

b) Some have pointed that it is ok if particular solutions do not work 
in some cases,
      as those concern allegedly "power user" who do not need help to 
set up tunnels...
      I disagree deeply with this assertion. Whatever we will do will be 
in use for many years,
      and things have to be done right and just works in any kind of 
environments.
      Relying on strong assumptions on how things are configured at 
customers place
      is, IMHO, a recipe for failure.

c) Anycast based solution are workable in theory but there are 
operational concerns.
     More feedback from the ISP community and the rest of the IETF is 
necessary.
     It may be the case that this should be the focus of a dedicated wg.

It seems, to me at least, that the logical conclusion is that we need 
to dissociate
this service discovery mechanism from the rest of the discussions and, 
for now,
consider that there is an out-of-band mechanism to find out the tunnel 
end points.

	- Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Jan 2005 16:49:28 +0100

On Tue, 2005-01-18 at 05:52 -0800, Alain Durand wrote:
> situations and in particular do not work well in the case where a NAT box is 
> present, which seems to be a show stopper.

Especially when thinking of the fact that without a NAT box one can
easily use 6to4, this 'solution' is really unnecessary.

> in some cases, as those concern allegedly "power user" who do not need help to 
> set up tunnels... I disagree deeply with this assertion. Whatever we will do will be 
> in use for many years, and things have to be done right and just works in any kind of 
> environments.

As long as there is a 'knob' to turn automatic on/off, or at least a
simple 'if there is IPv6 on the wire don't do a thing' this should be
fine with most if not all people. It should work in most (nearing 99%)
of the situations of course.

> customers place is, IMHO, a recipe for failure.

This is indeed the biggest point to learn from it all. There is simply
no way one can assume that a certain setup is available. We thus can
only assume there is IP and that we can send packets from A to B.

> necessary. It may be the case that this should be the focus of a dedicated wg.

Splitting up this, not even really started* WG into another WG is a bit
silly isn't it ? :) (especially when counting the number of _active_
participants)

> to dissociate this service discovery mechanism from the rest of the discussions and, 
> for now, consider that there is an out-of-band mechanism to find out the tunnel 
> end points.

Thus, if I am correct, the focus of this WG should be (in short):
 - the fully automatic discovery of the best possible TEP
 - the configuration of the addresses of the tunnel
 - the protocol used for the transport of the IPv6 packets over IPv4.

Maybe thus have 3 topics?
 - Endpoint Discovery
 - Configuration
 - Tunneling

Though I think that the discovery and the configuration could sometimes
come together. Though usage of eg DHCP and other standard methods could
solve these issues. Do note that there is little vendor support for
this.

Thus maybe simple prefix subjects with correct part (T,C,E) and done?

Greets,
 Jeroen

* = there is still no official IETF WG charter....

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Jan 2005 16:18:13 +0000

I agree with Jeroen.

I think though that originally we left the tunnelling protocol itself
out of scope, i.e. v6tc is tunnel *configuration* ?

Tim

-- 
Tim

---

From: Alain Durand <[email-masked]>
Date: Tue, 18 Jan 2005 08:42:20 -0800

> out of scope, i.e. v6tc is tunnel *configuration* ?

Thank you Tim for introducing the next issue I want to discuss...

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Jan 2005 21:17:50 +0200 (EET)

> easily use 6to4, this 'solution' is really unnecessary.

You can use 6to4 in this situation, yes, but you cannot use IPv6 
addresses from your service provider's v6 prefix.  6to4's return-path 
quality is always a bit questionable, and v6tc might allow one to get 
a stable prefix when 6to4 prefix could be dynamic.

So, while "you can use 6to4 in that scenario" is an answer, it is not 
a complete answer.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Jan 2005 08:52:40 +0100

> So, while "you can use 6to4 in that scenario" is an answer, it is not 

Ack. Isn't the best and already working route Teredo then:
 - NAT capable if needed
 - uses providers prefix
 - automatically configured

The only piece missing is the anycast prefix...

Greets,
 Jeroen

---

From: "Miguel Angel Diaz" <[email-masked]>
Date: Wed, 19 Jan 2005 09:38:56 +0100

> maintained for 10-20 years is a bad thing.

So the approach that Jeroen mentioned about using traceroute or ping would be an alternative. Furthermore, by using the IP of the customer's default gateway would be even better because it prevent the reverse done by some customers.

Regards
Miguel

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Jan 2005 11:35:37 +0200 (EET)

> The only piece missing is the anycast prefix...

Uhh, Teredo does not use provider's prefix.  (Though I'm not 100% sure 
whether a provider, by allocating a /32, could provide an "internal" 
Teredo prefix).

The anycast prefix was felt to be a big problem in Teredo, so 2 years 
(or so) ago the spec was revamped not to use it.

Of course, the v4 anycast prefix could be used just for discovery 
purposes (and then use a unicast address; see 
draft-ietf-mboned-auto-multicast-03.txt for example), but I'm not sure 
how much that would help.

Teredo also cannot be used by routers.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Jan 2005 10:43:21 +0100

> whether a provider, by allocating a /32, could provide an "internal" 

Last time I checked it did:

http://www.ietf.org/internet-drafts/draft-huitema-v6ops-teredo-04.txt
8<-------------------------------------------------------------------------
4 Teredo Addresses
   
   The Teredo addresses are composed of 5 components:
   
  +-------------+-------------+-------+------+-------------+
  | Prefix      | Server IPv4 | Flags | Port | Client IPv4 |
  +-------------+-------------+-------+------+-------------+
   
   - Prefix: the 32 bit Teredo service prefix.
   - Server IPv4: the IPv4 address of a Teredo server.
   - Flags: a set of 16 bits that document type of address and NAT.
   - Port: the obfuscated "mapped UDP port" of the Teredo service at
   the client
   - Client IPv4: the obfuscated "mapped IPv4 address" of the client
------------------------------------------------------------------------->8

And I am quite sure that Microsoft is using their 6bone prefix to fill in the first 32 bits...
What else could they use? 6to4?

> (or so) ago the spec was revamped not to use it.

But after all, it is nice to have, which was why it was in there.
I'll need to read up on all the negative aspects though why it was
revamped though. I recall it having to do a lot with anti-MS and ingress
filtering not being present and the latter thus causing security
problems.

> Teredo also cannot be used by routers.

Indeed only 1 host per address. In the beginning of, then silkworm,
Christian wanted 2003::/16 for this purpose, but that was rejected
because of a lot of anti-MS people shouting at the top of their lungs.
Not that 16 bits extra would give one much space for EUI-64.

Greets,
 Jeroen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 21 Jan 2005 09:45:10 +0100

Hi Pekka,

If my memory doesn't fails, I recall when I asked to Christian about why
anycast was not there anymore, he mention some complain from the IESG
review, but he also mention that using anycast just for the discovery.

I think this is the right way, not just for Teredo, but in general for any
protocol which requires a previous discovery process, and this is the reason
why we suggest it as a backup solution when you're not attached to the "home
ISP".

If we don't trust in that, then we should deprecate 6to4 ;-), which
obviously I don't think is the right thing to do !

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 19 Jan 2005 11:35:37 +0200 (EET)
> Para: Jeroen Massar <[email-masked]>
> CC: Alain Durand <[email-masked]>, <[email-masked]>
> Asunto: Re: Conclusion: Re: [v6tc] Issue 2: service discovery: automatic or
> manual?
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 22 Jan 2005 23:30:30 +0100

Partially agree, Teredo is missing the anycast bit, that's why our proposed
work started providing a solution for ALL the existing mechanism, not just
for TBs.

The other issue with Teredo is that doesn't work with all kind of NATs, so
this is once more a reason to be able to choose the most appropriate
encapsulation.

Regards,
Jordi

> De: Jeroen Massar <[email-masked]>
> Organización: Unfix
> Fecha: Wed, 19 Jan 2005 08:52:40 +0100
> Para: Pekka Savola <[email-masked]>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 22 Jan 2005 23:27:17 +0100

Agree also ;-)

I insisted even that we need to keep the encapsulation selection as part of
the protocol, but at that time, it was not clear that others support my
suggestion on this.

I think it will be pretty idiot to make a protocol that only supports a
single encapsulation, while almost the same protocol can support even 4in6
to cover scenarios that even when still not clearly described in v6ops, are
already in operational phase with real customers !

Regards,
Jordi

> De: Tim Chown <[email-masked]>
> Fecha: Tue, 18 Jan 2005 16:18:13 +0000
> Para: <[email-masked]>