[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-palet-v6ops-auto-trans-01 comments
Hi Pekka, all,
my reply bellow, in line.
> On Sun, 1 Aug 2004, JORDI PALET MARTINEZ wrote:
> > > substantial
> > > -----------
> > >
> > > In section 3.3, this doc goes on to state that building v6 tunnels over
> > > UDP is not always possible as some middle boxes don't forward those
> > > packets.
> > >
> > > I'd argue that this is a scenario we want to declare out of scope. If
> > > such a box really exists, it's more likely than not that the user is not
> > > supposed to punch holes in the NAT/firewall. We can simplify this a lot
> > > if we can remove whole section 3.3 and its subsections on HTTP, TCP or
> > > other tunnels.
> >
> > I partially don't agree. I agree that some times the "network
> > administrator" (i.e., enterprise), don't want to the user to punch
> > the NAT/firewall, but in some circumstances, the issue is more a
> > non-technical knowledge of the user to do that, so we need to
> > describe a solution (which can be or not provided in the specific
> > implementation).
>
> I'm not sure which scenario you're targeting and who you refer to with
> "user". Unmanaged networks? All of those NAT boxes etc. practically
> allow you initiate new outgoing UDP "sessions", right? Enterprise
> networks? Many allow outgoing UDP sessios as well, and those which
> don't disallow it for security etc. reasons and we don't want to
> cirucmvent that (and such organizations very likely block other kinds
> of packets as well, such as TCP so it wouldn't work in any case).
>
> Therefore I think having this consideration in the draft is
> counter-productive, at least without strong warnings and disclaimers.
>
The objective of section 3.3 isn't to overcome the filters that network administrators setup for security reasons but avoiding that non-technical users (everybody in general) can't enjoy v6 everywhere.
A lot of home-automation devices will come with IPv6 support. Such devices only will be used by the users if they have plug-and-play features. Of course with native IPv6 networks this support is guarantied, but what about IPv4 only domestic networks. Most of the time, users don't know anything about the configuration of their own network, so the auto-transition mechanism has to do the work instead the user.
The auto-transition mechanism (which can be implemented into the home-automation devices) will search the best way to get IPv6 connectivity if the NAT/Firewall box at the user's home is not configured to forward UPD/proto-41 packets.
Maybe the I-D should explain strongly this focus with warnings and disclaimers to avoid it become counter-productive.
> > > A possible list of mechanisms to be checked, ordered by
> > > preference
> > > could be:
> > >
> > > 7. DSTM
> > >
> > > ==> I think you can strike this from the list, because this draft
> > > discusses how to get v6 everywhere... DSTM already assumes v6, and is a
> > > solution for getting v4.
> >
> > Yes and not ... we are considering to extend this document to cover
> > both sides of the history ... then DSTM could play an important
> > paper there.
>
> I'd keep that out for now, or just cover it in an appendix (or the
> like)... because the auto-discovery on v6-only networks vs v4-only
> networks has really different assumptions..
>
yes, maybe you are right and including v6-only network items in this I-D is too ambitious. Maybe it is better to move DTSM to other further complementary I-D that addresses auto-transition in v6-only networks.
> > > ==> I don't quite understand how you mix MIPv6 into this. I didn't
> > > understand the second sentence (starting with "If chosen,..") or the last
> > > sentence (I mean, any mechanism is compatible with HA, as if you have HA,
> > > you can have whichever address at all because it's just your CoA).
> >
> > Yes, we mean that if MIPv6 is choosen as an option (either
> > automatically or by the user by means of a wizard), then ... The
> > problem here is if the user has access to a HA or not.
>
> You mean that the situation is greatly simplified if the user can use
> a Home Agent, but you'd want to also address the scenario where the
> user does not have a Home Agent?
>
> That's OK if you make it clearer, but I'd like to reconsider whether
> trying to reinvent (parts of) Mobile IP makes sense.. (it would better
> for the user to just use Mobile IP!) -- at least you shouldn't aim to
> achieve the same (but only a subset of scenarios) as Mobile IP..
>
If user can't reach a HA, it means that MIPv6 capability can't be used. We don't like to solve the point that using MIPv6 when no HA is available. We have enough stuff in this I-D ;-)
In general, the inclusion of MIPv6 concepts in the I-D is to address devices that need to be tracked (cars, suitcases, etc.). If MIPv6 has to be used, it will influence on the selection of the transition mechanism because it can't have the IPv4 address embedded into the IPv6 one, that is, the IPv6 address can't depend on the IPv4 network where the device is attached to. Section 4 tries to explain this.
> > > ==> this section seems overlongly long and detailed.. I think the basic
> > > thing you're saying is that the network could provide a means to help the
> > > user choose their mechansism (my example: e.g., a DNS record),
> > > describing different options and possibly giving preferences as well.
> > > This is in particular because policy-based networks didn't really get
> > > into a good swing and get deployed. Thus, I'd only keep the first 1-2
> > > paragraphs, and those from the end starting with "Whether the network
> > > provides"..
> > >
> >
> > Our point here is precisely that the provision of PBN could motivate
> > the ISPs to start the transition, because they can take the
> > opportunity to do other "policy" based services at the same time. Is
> > not only a DNS record, but a managed transition that also provides
> > the ISP the way to control the process and provide higher quality of
> > the transition service.
>
> I mean, do you suggest that the ISP would deploy PBN just (initially)
> for v6 transition? This doesn't seem practical to me.. and I doubt
> that it would happen -- hence I would like to reduce the emphasis of
> PBNs here. It's really something that should be described in a
> totally separate I-D (or appendix, or whatever).
>
No, we don't mean that ISPs would deploy PBN just for v6 transition. Transition policies would be only one more service that ISPs might offer, just in case they have already deployed PBN for other services like security, routing, QoS and so on. If so, the auto-transition will take advantage of it to easily manage the v6 connectivity. If don't so, the auto-transition mechanism has to work also, likely less easily.
Our main focus is on the user side, so the auto-transition behavior is defined according to that approach. However, the v6 connectivity process can be improved if the network provides some useful information to the auto-transition mechanism. For this reason we describe what we call Network Managed Transition.
From the network approach, PBN seems to be a good alternative to help ISP to provide different types of access to users according to their category, that is, a golden user would have better QoS, so ISP could offer a different transition mechanism than a bronze user with poorer QoS. Interactions among different policies like type of user (AAA), QoS and transition mechanism to be used can be supported on this framework. Given the fact that this new approach open new powerful possibilities, it is worth to address it as much as possible.
> > > o detect_scenario: This task deals with detecting the scenario where
> > > the device willing to have IPv6 connectivity is located. It could
> > > check if native IPv6 is available, if a public IPv4 address is
> > > available, if a NAT is being used and what type, if there is a
> > > proxy or firewall, or if other protocols can be operated.
> > >
> > > ==> I'd do s/and what type/(and possibly what type)/ because it might not
> > > be feasible to do that in auto-trans, if the mechanism has to detect the
> > > NAT type (like Teredo) in any case -- or were you referring to whether it
> > > forwards proto-41 or not?
> >
> > I don't understand why you say that auto-trans can't do that ? Or
> > you mean that is not useful because is done already by the mechanism
> > itself ? But if so, that only happens once the mechanism is
> > launched, and auto-trans goal is to select the right mechanism
> > before its started.
>
> Yes, I meant that it probably isn't feasible to do that by auto-trans
> because it's done by the mechanisms. If you do that prior to
> launching the mechanism, you do a lot of duplicate work. If you do it
> after launching a mechanism, you aren't really "detecting" anything in
> auto-trans, just using the knowledge which the mechanism learned about
> the environment.
>
> How I see this is that auto-trans, in its most basic form, should
> first try to cut down the number of mechanisms to evaluate based on
> "passive analysis" (e.g., checking whether IP address is private or
> not).
>
> After that, it needs to test the mechanisms in some order: that could
> be done either by launching the mechanism and seeing if it succeeds or
> not (and if not, try to figure out how it failed, and try the next
> one), or by reproducing some code from the mechanisms and try to do
> some "active investigation" in the network itself (e.g., send a
> specific kind of test packet outside (where?) and see if you get it
> back). The former approach would possibly be preferable.
>
>
why can't the auto-transition mechanism check the NAT type? The result of such a test will strongly influence on the type of transition mechanism to be choosen /checked (6in4, Teredo, etc). For exameple: if the NAT box doesn't forward proto-41, why to check 6in4 tunnels? So the auto-trans should do it. Then a reduced list of mechanisms fitting with the NAT check result will be choosen from the general candidate list in order to check it some of them can be choosen.
I agree this behaviour can duplicate the work if the final mechanism also check the type of NAT (Teredo), but not all of them do it, so it is necessary, even although some times it means duplicate work
Best Regards
Miguel
**********************************
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.