[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: other comments on draft-nielsen-v6ops-3GPP-zeroconf-goals-00. txt
Hi Alain,
Thanks a lot for your comments.
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]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.
>
>