[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
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.
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?
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.
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.
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.
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).
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..
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"..
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/
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".
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/
We should understand that the auto-transition goal is to facilitate
an adecuate transition to IPv6. Towards that, it tries to
==> s/adecuate/adequate/
given scenario, which may be not the perfect one. Actualy
implementing a perfect auto-transition solution could be a very
complicated,
==> s/Acutaly/Actually/
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.
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?
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?
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"
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.
Different transition mechanisms have different IPv6 type of end
points.
==> "IPv6 type of end point" was a bit odd confusing word selection.
4. Nomadicity Considerations
==> would it be useful to split the two nomadicity cases to their own
subsections?
* 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 ?
If there are not such
agreements, automatic connectivity is not possible and the
auto-transition algorithm has to options:
==> s/to/two/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings