Subject: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt

From: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
Date: Fri, 5 Nov 2004 13:03:37 +0100

Hi Alain,

Thanks a lot for your comments.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Alain Durand
> Sent: Friday, November 05, 2004 7:47 AM
> To: '''IPv6 Operations ' ' '
> Subject: other comments on
> draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt
> 
> 
> Direct tunneling:
> -----------------------
> I would have like this document to take a stance with regard 
> to direct  
> tunneling.
> Is it needed or not? I found section 3.2 confusing:
> 
>  > 3.2. IPv6 tunnel link characteristics, Scope and Limitations:
>  >
>  >   Direct tunneling is neither an explicit goal nor 
> explicitly excluded
>  >   in Zero-Configuration Tunneling in the 3GPP network environment.
> 
> Specially when later, section 9.3 says:
>  > 9.3. Implications of Direct Tunneling
>  >
>  >   In case direct tunneling in between end-hosts is provided by the
>  >   tunneling protocol, it will not (as described in Section 
> 9.2.1) be
>  >   possibly for end-hosts to filter out received Protocol-41
>  >   encapsulated packets based on whether the IPv4 source is 
> an address
>  >   belonging to a trusted Tunnel Server as such behavior evidently  
> would
>  >   break direct tunneling.
>  >
>  >   As other end-hosts generally are non-trusted, direct 
> tunneling may
>  >   thus open up for attacks against IPv6 ingress filtering.
> 
> The logical conclusion of section 9.3 seems to be that for security  
> reasons,
> direct tunneling should not be allowed and thus be a non goal 
> of this  
> document...
> Unless, of course, there is a strong rationale for direct tunneling  
> that should be spelled out
> in section 3.2
> 
> 

The situation in my mind in the following:

No, direct tunnelling is not a prerequiste.
But, if direct tunnelling is provided in a secure way, then why not.

As you have pointed out this could be said more clearly in the doc.
If people disagrees with allowing secure direct tunnelling, then it will
have to be changed altogether, of course. 

> Tunnel end-point discovery
> -------------------------------------
> This document should also reference
> http://www.ietf.org/internet-drafts/draft-yamamoto-naptr-service- 
> discovery-00.txt
> 

Yes, now it should. Thanks.
Let me and the other authors think about how it should be put exactly, I have a 
small concern with this in the 3gpp environment due to RT delays (more or that to come).

> No support for PAN
> --------------------------
>  > 3.1. IPv6 address allocation, Scope and Limitations:
>  >
>  >   The primary goal of 3GPP Zero-Configuration Tunneling is 
> to provide
>   >  IPv6 connectivity to nodes on an individual basis. By this it is
>   >  meant that it is only an explicit goal to have a /128 address
>   >  allocated for global connectivity on the tunnel link. As such  
> optimal
>   >  IPv6 connectivity provisioning in Personal Area Network (PAN)
>   >  scenarios is not explicitly within the scope of 
> Zero-Configuration
>   >  Tunneling.
> 
> What does the phrase "optimal IPv6 connectivity provisioning in PAN"  
> means?
> The word 'optimal' confuses me...
> 

Well you may support a PAN by allocating each of devices in the PAN
a seperate address and its own tunnel for external communication. They will
not get a /64 prefix to share however.

They may communicate with each other using the tunnels to the tunnel server
(thats where the unoptimal) comes from. They may also of course commmunicate
internally using some ad hoc routing protocols but the PAN cannot be based
on simpel lan (one one-link prefix) communication.

> I find this section a bit restrictive, as it is not difficult 
> to design  
> a zeroconf mechanism
> that will enable prefix delegation with a simple router 
> advertisement  
> sent over the tunnel.
> Also, this is a violation of RFC3177 which recommends 
> allocation a /64  
> to cell phone
> especially in order to support PAN...
> I would like to see at least better rationale why PAN support is not  
> deemed important
> or why it would introduce unjustifiable complexity.
> 

I don't think that it is a problem per se that a transistion mechanisms
doesn't provide what native IP does. Specifically it is not a problem
per se that the address provisioning of a transition mechanism isn't 
in compliance with RFC3177.

It is a problem, of course, if the transition mechanism does not support the deployment
scenarios that it is envisaged for. In the 3gpp environment, PAN applications aren't like
the first IPv6 applications that one are looking to pilot and as such no one have
come forward with requirements for the tunnelling mechanism to support the PAN scenario.
- Consequently when looking for the minimal set of requirements, it has not been found worthwhile 
to bind the solution to support the PAN scenario, also.

Note that there are a lot of applications, much more in focus than the PAN scenario,
that the tunnelling mechanism cannot solve anyway due to the dependence on various 
intrinsic 3gpp functions which won't support the transistion scenario.

With respect to the complexity issues of introducing prefix delegation, I will take the liberty
to repeat once more that we have tried to stick to the requirements of the deployment scenarios
and have not introduced something as a requirement simple because it was considered feasible. 

Don't take me worng, I agree that this is not a simple "black and white" issue.

> Timing (section 5)
> ---------
> Although I understand very well that time to market is the 
> essence of  
> this work
> and this is good background information, section 5 should be removed  
> from the final
> document.
> 

I agree.

Right now it is there, also to emphasize why the "3gpp people" (as Pekka
terms us, I think) were reluctant to broaded the scope of the document with the risk
of introducing additional delays.

BR, Karen

> 	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Nov 2004 15:37:28 +0200 (EET)

One comment on a comment,

On Fri, 5 Nov 2004, Karen E. Nielsen (AH/LMD) wrote:
> Let me and the other authors think about how it should be put 
> exactly, I have a small concern with this in the 3gpp environment 
> due to RT delays (more or that to come).

Let me disagree here, rather strongly.

The requirements document like this should not point at various 
solutions documents.  In the case of tunnel endpoint discovery, we 
have a good document (draft-palet-v6ops-tun-auto-disc-00.txt) -- which 
could include more discussion relating to draft-yamamoto-, but there 
is no need to refer to that *HERE*.

However, as there are a *LOT* of different tradeoffs regarding tunnel 
end-point discovery, it makes sense to elaborate a bit on the 
tradeoffs of 3GPP.  For example, whether DHCP could be used (I think 
not); whether DNS lookups are feasible; how many round-trips should be 
the maximum; whether this could be piggybacked on a 3GPP configuration 
protocol; whether the mechanism should fail gracefully (and after how 
many attempts) if the service is not found; etc.

-- 
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: Fri, 05 Nov 2004 17:30:29 +0100

Hi Pekka,

You mean including in the next version of draft-palet-v6ops-tun-auto-disc
something specific to 3GPP considerations ?

No problem in doing that. Will try to work on this next week, but can't
promise being so fast this time !

Also, we have already some text regarding NAPTR, but we can expand if
required. Any specific suggestion or text that someone want to propose ?

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: [email-masked]
> Fecha: Fri, 5 Nov 2004 15:37:28 +0200 (EET)
> Para: "Karen E. Nielsen (AH/LMD)" <[email-masked]>
> CC: "'Alain Durand'" <[email-masked]>, "'''IPv6 Operations ' ' '"
> <[email-masked]>
> Asunto: RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 

**********************************
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: Pekka Savola <[email-masked]>
Date: Fri, 5 Nov 2004 19:27:24 +0200 (EET)

Hi,

On Fri, 5 Nov 2004, JORDI PALET MARTINEZ wrote:
> You mean including in the next version of 
> draft-palet-v6ops-tun-auto-disc something specific to 3GPP 
> considerations ?

Not really, though if it's believed that 3GPP's case differs 
significantly in scenarios in section 2, more text could be added 
there.  I'd think the 3GPP should be already rather well covered there 
and in the other documents.

I was referring that the 3GPP goals document might want to expand a 
bit on its endpoint discovery requirements.

See below..

> promise being so fast this time !

No big hurry with this.

> required. Any specific suggestion or text that someone want to propose ?

This was more what I was after with respect to 'tun-auto-disc' 
solution.  If Alain thought the current reference to 'tun-auto-disc' 
was not sufficient, that seemed to hint that the attributes of the 
solution might not have been sufficiently discussed in tun-auto-disc.

As to the attributes of the reverse lookup schemes, one might say a 
few good / bad sides, like:
  - bad side is that requires a lot of records
  - also requires some kind of special population of the private 
address space etc. if used between the user and the customer, pretty 
ugly.
  - increases the number of required lookups
  - on the other side, allows more flexible, IP-specific configuration

Also, two particular more generic issues, AFAIR, which could be 
discussed a bit more might be:

  - the "granularity" of the discovery process, i.e., how precisely and 
easily should you be able to modify the results of the lookup, e.g., 
tune that hosts A..B within a single administrative domain should 
discover X, hosts B..C should discover Y, etc. (for example, when 
using DNS, one way to achieve this would be split-faced DNS, or 
looking up stuff from the reverses like Alain proposes).

  - the manageability domain of the host.  It can be argued that IP 
addresses are often more "local" than host names.  A search path could 
include even all of the enterprise, all over the world, while 
customizing the lookup results (above) based on the IP address might 
go closer to the administrative domains.

It could also be argued that this may not be all that severe a problem 
here, if DNS is combined with anycast (provided that split DNS is not 
used).  Even if node X gets the same IP address everywhere by looking 
up x_srv.example.com, x_srv.example.com can be anycasted, set up 
everywhere using the same IP address.

But as said, there are certainly a lot of arguments for or against 
about this kind of customization.

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Nov 2004 09:31:27 -0800

Pekka Savola wrote:

>> exactly, I have a small concern with this in the 3gpp environment due 
>> to RT delays (more or that to come).
>
>

We might be in violent agreement. My point is that either the 
requirement specs reference
all possible solutions or none and stick to requirements.
Referencing only one potential solution is wrong.
That said, I agree that all the tunnel end point discovery solutions 
should be merged.

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Nov 2004 10:03:12 -0800

>required. Any specific suggestion or text that someone want to propose ?
Jordi,

I could send you some text summarizing the NATPR solution,
but this is not what is needed the most at this point in time.

IMHO, we need to understand what are the real requirements
of the different customers (read assisted tunnels, zero conf & 3GPP, 
potentialy others)
and compare the different solutions with those requirements.

I believe that the 3 customers have the same fundamental need,
i.e. a DHCP based solution won't work (difficult to deploy),
there is a desire to match the underlying topology as well as possible,
and the number of round-trip should be minimize, especially in the 3GPP 
case.

So, I agree with your conclusion in draft-palet-v6ops-tun-auto-disc-02.txt
that a DNS based solution is the right approach. The point to discuss
is should this be done in the forward or reverse DNS tree? I tend to preffer
doing it in the reverse tree because it matches the physical topology.
The only argument so far I've heard against it is the number of packet 
exchange necesssary,
(2 instead of 1) however there is a solution to that by padding data in 
the additional section,
same as what is done for CNAME.

I hope we could find time in D.C. to discuss this further and have the 
wg come
with a single recommended solution.

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Nov 2004 10:31:02 -0800

>   - bad side is that requires a lot of records

    not an issue as they can be generated with script.

> address space etc. if used between the user and the customer, pretty 

This is an area that need invetigation, I agree.

>   - increases the number of required lookups

Not necessarily. Think CNAME and additional section.

>   - the "granularity" of the discovery process, i.e., how precisely 
> and easily should you be able to modify the results of the lookup, 
> e.g., tune that hosts A..B within a single administrative domain 
> should discover X, hosts B..C should discover Y, etc. (for example, 
> when using DNS, one way to achieve this would be split-faced DNS, or 

In practice, I think this is an important operational issue.

> go closer to the administrative domains.

Search path are just plain wrong. As I explained several times, 
internally at Sun, we have domains
that span the planet and many hosts are`configured with several domains 
in their search path.

> everywhere using the same IP address.

That makes the asumption that we know how to limit the propagation of 
anycast routes
within large domains. This is certainly doable, but the associated 
complexity is large.

    - Alain.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 05 Nov 2004 19:30:15 +0100

Hi Alain,

Our document is doing an analysis of all possible solutions. Our suggested
solution is a different document.

Our analysis document already includes NAPTR description, but we may need to
expand to reverse, which will be the right way to proceed with an analysis
document to be as much comprehensive as possible.

Regards,
Jordi

> De: Alain Durand <[email-masked]>
> Fecha: Fri, 05 Nov 2004 09:31:27 -0800
> Para: Pekka Savola <[email-masked]>
> CC: "Karen E. Nielsen (AH/LMD)" <[email-masked]>, "'''IPv6
> Operations ' ' '" <[email-masked]>
> Asunto: Re: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
> 
> Pekka Savola wrote:
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 05 Nov 2004 19:41:24 +0100

Hi Alain,

I think is not really a summary what we need. The idea, in the analysis
document is to look at the pros and cons of every possible solution.

Pekka just did a very good job mainly with the cons for NAPTR, so I guess it
will be good if you can summarize the cons that we may be missing.

Your suggestion about how to approach the solution document seems quite good
to me. We can try to look into the different type of scenarios and see what
pros and cons has each possible solution, but I think is much easy and we
will come out to the same conclusion with the existing layout. May be I'm
wrong on this anyway.

Actually when you talked to me about your view on the reverse DNS, I was
initially very convinced, but when back in Madrid, checking pros and cons,
we come out to some of the (mainly) negative points (versus forward DNS),
which Pekka summarized already.

But agree, we should take a look again to all the options.

Regards,
Jordi

> Fecha: Fri, 05 Nov 2004 10:03:12 -0800
> Para: [email-masked]
> CC: [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Nov 2004 22:33:01 +0200 (EET)

These can certainly be argued many ways, and hopefully these issues 
can be captured in a revision of palet-tun-auto-disc..

On Fri, 5 Nov 2004, Alain Durand wrote:
>> As to the attributes of the reverse lookup schemes, one might say a few 
>> good / bad sides, like:

Still, doing so either requires that script be invented and 
(re-)written by every DNS admin, or be distributed with DNS servers.
The script is probably very trivial, yes, but this is an ease-of-use 
factor.

If we want to make it extremely simple to set up these services this 
could be a small minus.

> Not necessarily. Think CNAME and additional section.

CNAMEs in reverse tree?  Granted.  Hopefully no DNS servers would 
break with such unanticipated usage.

>> Also, two particular more generic issues, AFAIR, which could be discussed a 
>> bit more might be:
>> 
>> easily should you be able to modify the results of the lookup, e.g., tune 
>> that hosts A..B within a single administrative domain should discover X, 
>> hosts B..C should discover Y, etc. (for example, when using DNS, one way to 
>> achieve this would be split-faced DNS, or looking up stuff from the 
>> reverses like Alain proposes).
>

Yes, it could be; depends a lot on how the network has been set up, 
who are in charge of the deployment of the tunnel endpoint (routing 
people, DNS people, or ...)

>> include even all of the enterprise, all over the world, while customizing 
>> the lookup results (above) based on the IP address might go closer to the 
>> administrative domains.
>
> internally at Sun, we have domains that span the planet and many 
> hosts are configured with several domains in their search path.

I don't see anything fundamentally *wrong* with the search path usage. 
Yes, under certain set-ups, it is difficult to discover *really* the 
closest relay just by using the DNS, but that's where routing can 
help.  Multiple searchpaths provide simple fallbacks as well.

>> used).  Even if node X gets the same IP address everywhere by looking up 
>> x_srv.example.com, x_srv.example.com can be anycasted, set up everywhere 
>> using the same IP address.
>
> That makes the asumption that we know how to limit the propagation 
> of anycast routes within large domains. This is certainly doable, 
> but the associated complexity is large.

This seems simple routing basics.  Actually, you probably even don't 
need to propagate any host routes across different areas of a large 
domain.  Everyone just uses the same address to configure the 
topo/geographically distributed tunnel boxes, and it will go towards 
the closest one, either through a host route, or following the default 
route.

(Truth in advertising,) I see only a couple of minor problems with 
this:
  - if the number of boxes grows huge, beyond e.g. half a dozen, a 
large number of identically numbered boxes might get difficult, 
debugging-wise.  But as this is just a transition mechanism, it should 
be OK..
  - if the enterprise is divided to multiple autonomous systems or 
similar routing constructs, and you'd wish to deploy some boxes in 
those, and some out of them, the ingress filtering between the borders 
of those routing domains might get a bit complicated (might need to 
add one ACL line as an exception), depending on which IP address pool 
the address was taken from.

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Nov 2004 13:38:26 -0800

> The script is probably very trivial, yes, but this is an ease-of-use 

This is a bogus argument. Such a script already exist for generating 
the PTR in the reverse zone.
I wrote a very small ad-hoc perl script (10 lines of code!) to do that, 
I can donate it to the community
if need be.

Another way to solve this non-issue is to get $generate to be adapted 
to generate NAPTR as well.

> break with such unanticipated usage.

No. I should have been more clear...
When you are resolving a name in the forward tree and there is a CNAME, 
you generally do not
have to do a second query to resolve the CNAME. As the server knows you 
are more than likely to
need that data anyway, it puts it in the additional section. Example:
[halibut:~] alain% dig ftp.sun.com a

; <<>> DiG 9.2.2 <<>> ftp.sun.com a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11219
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ftp.sun.com.                   IN      A

;; ANSWER SECTION:
ftp.sun.com.            86400   IN      CNAME   supportfiles.sun.com.
supportfiles.sun.com.   86400   IN      A       192.18.108.101

;; Query time: 87 msec
;; SERVER: 64.81.79.2#53(64.81.79.2)
;; WHEN: Fri Nov  5 13:36:25 2004
;; MSG SIZE  rcvd: 72

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Nov 2004 23:49:44 +0200 (EET)

On Fri, 5 Nov 2004, Alain Durand wrote:
>> Still, doing so either requires that script be invented and (re-)written by 
>> every DNS admin, or be distributed with DNS servers.
> the PTR in the reverse zone. I wrote a very small ad-hoc perl script 
> (10 lines of code!) to do that, I can donate it to the community if 
> need be.

I was not arguing that such scripts would not exist, and many admins 
would probably be qualified to write it pretty easily if they just 
bothered to do that.  The point is that the other admins don't know it 
exists when they think of the problem they want to solve, and 
discredit the solution as requiring manual insertion for the lack of 
better tools.

>> CNAMEs in reverse tree?  Granted.  Hopefully no DNS servers would break 
>> with such unanticipated usage.
>
> No. I should have been more clear... When you are resolving a name 
> in the forward tree and there is a CNAME, you generally do not have 
> to do a second query to resolve the CNAME. As the server knows you 
> are more than likely to need that data anyway, it puts it in the 
> additional section.

Sure -- what I'm having difficulty understanding is why you're talking 
about forward tree when the proposal was about reverse tree?

---

From: Alain Durand <[email-masked]>
Date: Fri, 05 Nov 2004 14:05:57 -0800

On Nov 5, 2004, at 1:49 PM, Pekka Savola wrote:

>  The point is that the other admins don't know it exists when they 
> think of the problem they want to solve, and discredit the solution as 
> requiring manual insertion for the lack of better tools.

Honestly, this is FUD.

> about forward tree when the proposal was about reverse tree?

Because the fact that the suggested use of NAPTR is in the reverse tree 
DNS is irrelevant to the number of
packet exchange. In draft-yamamoto-naptr-service-discovery-00 the NAPTR 
record points to a name
that then must be resolve into an IPv4 address, thus the potential 
extra packet exchange that can be avoided
using the same 'trick' as CNAME, i.e. padding data in the additional 
section.

	- Alain,

---

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Nov 2004 14:52:49 +0200 (EET)

On Fri, 5 Nov 2004, Alain Durand wrote:
>>  The point is that the other admins don't know it exists when they think of 
>> the problem they want to solve, and discredit the solution as requiring 
>> manual insertion for the lack of better tools.
>
> Honestly, this is FUD.

Whether true or not can be debated, but certainly something that would 
come up operationally.

...

A couple of afterthoughts..

From a higher view, another generic problem with reverse approach is 
that it does not work well (AFAICS) if the reverses have been 
delegated.  That will mean that each server has to do this 
configuration.  I don't know what's the typical procedure, but I'd 
expect e.g. bigger enterprises would have their own authorative 
servers for different bigger national branches, etc.  -- if yes, 
managing this information consistently is an operational challenge.

That said, the approach seems to be fairly good when you're only 
considering one administrative domain, and the tunnel point deployed 
in that administrative domain.  But isn't that scenario equally 
addressed with a DHCP option, using a more operator-friendly approach?

---

From: Alain Durand <[email-masked]>
Date: Mon, 08 Nov 2004 08:11:49 -0800

> addressed with a DHCP option, using a more operator-friendly approach?

The practical problem with the DHCP approach is that you need to update 
both the DHCP server
and all the DHCP clients, which is very difficult because of all the 
legacy systems.
In a typical home network, the soho router act as the local DHCP server 
for the local hosts,
and it also sometimes act as a DHCP client to get config from the ISP.
In that scenario, using DHCP won't work unless you are ready to change 
all the CPEs...

So I echo what Karen said, DHCP is not a practical avenue.

    - Alain.