[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-palet-v6ops-auto-trans-01 comments
Hi Pekka,
See my reply below, in-line.
Regards,
Jordi
---- Original Message ----
From: "Pekka Savola" <pekkas@netcore.fi>
To: <v6ops@ops.ietf.org>
Sent: Sunday, August 01, 2004 7:44 AM
Subject: draft-palet-v6ops-auto-trans-01 comments
> 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).
>
> semi-substantial
> ----------------
>
> A number of transition mechanisms have been defined already: Teredo,
> TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, DSTM, etc. All of them work
> when the host willing to get IPv6 connectivity has a public IPv4
> address. Even some of them also work when the host is located behind
> a NAT box that allows proto-41 forwarding [3]. However there are
> other kind of NAT boxes that prevent the current transition
> mechanisms to work, so there is a gap that could be filled with new
> kind of solutions, possibly layer 2 or layer 4 tunnels.
>
> ==> the sentence starting "However" seems to imply that NAT boxes which
> don't allow proto-41 forwarding don't work with these mechanisms,
> requiring new ones... which is not quite the case for Teredo, TSP, and
> STEP at least.. requires rewording.
Yes, you're right. I will find a better wording to avoid that misunderstanding. I will also put concrete references to all those mechanisms.
>
> loop
> detect_scenario
> if (native_IPv6_available and native_priority)
> use_native_IPv6_connectivity
> else
> if (first_check or performance_check_allowed)
> check_performance
> use_best_mechanism
> endif
> endif
> configure_connectivity
> wait (link_check_timeout)
> endloop
>
> ==> this algorithm doesn't actually work (AFAICS) because
> use_best_mechanism is inside the loop. Shouldn't it be outside the loop?
> Or did you mean that it selects the best of *so far* configured/tested
> mechanisms?
Yes, once we detect the scenario, and what mechanisms are possible, and which one is "best", then we actually enable it.
>
> 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.
>
> 3.2 Change of transition mechanism
>
> ==> this section, or something close to it, should probably discuss when
> it makes sense to have multiple transition mechanisms active at the same
> time. For example, you might still want to activate 6to4 even if you have
> a tunnel, for optimization purposes.
You mean activate multiple transition mechanism and actually make use of both ? Not really sure if we want to put the host in a multi-homing situation. Is this good ?. Or I'm not figuring out what you are trying to say ?
>
> 1. Nodes that do not need to maintain the IPv6 address assigned from
> their home TS. They are typically nomadic users who get
> connectivity to "passive" Internet users (browsing, emailing,
> etc.), but do not need to be "identified" from Internet
> (nevertheless this situation is changing with next generation p2p
> applications, VoIP, etc.).
>
> ==> it's actually not as simple as that. You assume that the
> identification would have to be done based on the IP address. In many
> cases, that's probably a bad choice, but should be done e.g., based on
> DNS or some p2p naming/rendezvous system. IMHO, we want to get to the
> point where the IP address you have doesn't make much difference, because
> you're using layers of indirection like DNS... and the only thing you may
> need to worry about is connection survivability which is what MIPv6 and
> multi6 designs will fix if you don't get the same IP address.
Yes, this may require further clarification/work. But today, for stable services, most of the time you use DNS, and this is associated to a specific (not dynamic) IP address ...
>
> 2. Nodes that need to maintain the IPv6 address assigned from their
> home TS. Users belonging to this group are typically users with
> either server or peer-to-peer applications, devices that need to
> be tracked (cars, suitcases, etc.), etc.
>
> ==> here, again, you make an assumption that tracking would have to be
> done based on the IP address. That's not necessarily the case, but in
> this particular scenario, I the more natural way would be to actually
> track it.
>
> * Mobility capability should be an option that should be
> configured by means of the installation wizard. If chosen,
> the first time that the auto-transition algorithm is run, it
> must check if a Home Agent (HA) exists either in the current
> IPv6 network or in the TS. In fact, this option should
> condition the order of searching for the best transition
> mechanism to get IPv6 connectivity. In this way, only
> mechanisms compatible with the presence of HA should be taken
> into account (mechanisms providing static IPv6 network prefix
> like TB, TSP, ISATAP, etc.).
>
> ==> 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.
>
> On the other hand, the
> auto-transition algorithm should discard transition mechanisms
> that build the IPv6 network prefix from the IPv4 address
> (6to4, TEREDO, etc.). This is required because it is no
> possible the deployment of the HA into the same IPv6 network,
> so no mobility features would be possible.
>
> ==> I didn't quite understand the second sentence here either..
I need to check with the previous version, because I'm also confused here myself ;-)
>
> 5. Network Managed Transition
>
> ==> 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.
>
> editorial
> ---------
>
> The main goal is to facilitate the IPv6 deployment in a seamless way
> for devices, users and applications. Lots of devices and
> applications around us will benefit obtaining IPv6 connectivity
> everywhere:
>
> ==> s/benefit/benefit from/
Ok.
>
> o End devices: Devices that do not intend to provide IPv6
> connectivity to others. They are typically devices that would get
> IPv6 connectivity by means of Router Advertisement if they were
> attached to a native IPv6 scenario.
>
> ==> remove "scenario".
I will use network instead of removing scenario.
>
> etc. They should provide native IPv6 connectivity to the whole
> network(s) located behind them by announcing an IPv6 prefix. With
> this approach this kind of devices will be plug-and-play,
>
> ==> s/this/these/
Ok.
>
> We should understand that the auto-transition goal is to facilitate
> an adecuate transition to IPv6. Towards that, it tries to
>
> ==> s/adecuate/adequate/
Ok.
>
> given scenario, which may be not the perfect one. Actualy
> implementing a perfect auto-transition solution could be a very
> complicated,
>
> ==> s/Acutaly/Actually/
Ok.
>
> in the case it happens, could
> bring us the paradigm that there is no anymore an incentive for
> native IPv6 connectivity, which clearly is in contradiction with this
> memo goal and in general the IPv6 deployment one.
>
> ==> reword the end: s/memo/memo's/ and the last few words somehow.
Ok.
>
> The auto-transition algorithm may take into account not only the
> results shown in [8], because it is also possible a wider focus to
> select the best transition mechanism to be used.
>
> ==> something missing in the middle line -- I can't parse it?
What I try to say is that we don't believe the auto-transition should be limited to the mechanism described in [8]. Will reword it to make it clearer.
>
> 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.
> So, for
> instance, if the device running the auto-transition algorithm
> needs to contact with a TB different to the actual one and it
> requires user authentication, the process should be transparent
> to the user.
>
> ==> I didn't quite understand which TB is the "actual one"
In the case that you are already connected, for example, to a TB and you're moving to a network that offers a better TB option (nearer one).
>
> If native IPv6 connectivity is provided
> by the ISP and used, this TS will be obviously the link end point and
> no further work is required.
>
> ==> this is a slighly confusing way to say that if you have native v6, you
> don't run any tunnel (except for special cases, e.g., 6to4),
> and you don't even need to discover the end-point.
Ok.
>
> Different transition mechanisms have different IPv6 type of end
> points.
>
> ==> "IPv6 type of end point" was a bit odd confusing word selection.
Probably should be "different IPv6 end points".
>
> 4. Nomadicity Considerations
>
> ==> would it be useful to split the two nomadicity cases to their own
> subsections?
Ok.
>
> * TSs that do not require authentication process. They are TSs
> that provide IPv6 connectivity and they do not make any
> authentication process (TEREDO, 6to4, etc.). This approach
> does not represent any innovation, so the auto-transition
> algorithm just contact to the TS and the IPv6 connectivity is
> obtained.
>
> ==> "doesn't represent any innovation" -- I don't understand, remove ?
Possibly "The auto-transition approach doesn't represent any advantage in this case".
>
> If there are not such
> agreements, automatic connectivity is not possible and the
> auto-transition algorithm has to options:
>
> ==> s/to/two/
Ok.
**********************************
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.