Thanks. You have answered my basic question in that it is possible to
encode individual ISATAP subnet prefixes, and I accept that'll probably
work for most people (together with the assumption that RFC1918 IPv4 +
NAT is now "global.")
I'm just trying to explore the boundaries and assumptions here via use
cases. If it isn't helpful to you, just let me know.
The only mechanism that I know of for selecting between the preference
order for alternative encapsulations is RFC 3484 (and your proposed RFC
3484 bis) or hard coding. All initiatives so far seem to make certain
assumptions about the desirability of various preferences. (e.g.
paraphrasing some history: IPv4 is going to be awful so prefer IPv6). We
can discuss requirements and defaults, but I think a discussion on
flexibility and being able to over ride the default might also be useful.
The reason that this has an impact on network managers, as I'm sure
you're aware, is that although there is often a fall back mechanism to a
different encapsulation method, this fall back takes a finite amount of
time, which may or may not be an operational problem depending on a
particular SLA. See e.g. happy eyeballs, although I can think of more
extreme examples like control and trading systems where certain
protocols require a different preference setting. So being able to
tightly manage the selection preference order could be critical to some
network managers.
I don't have a real "problem" with the current default for ISATAP. I
find it unfortunate for my particular needs that I can think of today,
that's all.
Different people have different requirements and SLA'a and transition
paths. We are very early in the transition to IPv6 and I read all sorts
of assumptions and debates on various blogs about the suitability of
various preference schemes and protocols. In reality I'm not sure anyone
knows the "correct" answer at this time, and certainly not the "single
correct answer." The reality is that transition will probably be a
process. RFC3484 was probably the "right thing to do" at the time, but I
think we all agree it needs at least some updating. Once again thanks
for taking the lead in this.
I certainly recognise that any one version of requirements may not be
universal. In fact I acknowledge that the version I have presented is
probably more driven by latency SLA's than most.
Some people may want a use case of native IPV6 >> native IPv4 >> tunnel
protocols if they want to build networks with great IPv6 connectivity
whilst keeping native IPv4 in production if they have certain SLA issues
and requirements.
The opposite case may also be true for people who have great IPv4
connectivity, but that their native IPv6 connectivity is somehow broken
(I can think of a local CPE router which advertises IPv6, but the
intermediate native IPv6 connectivity is broken due to a non-conformant
device e.g. firewall) So people may actually prefer a tunnel over IPv4
versus a native protocol.
That use case would be particular_tunnel_protocol >> native IPv4 >>
native IPV6
Some people use RFC 1918 address on their local LANs. Others use PI IPv4
space (Teredo makes an assumption that PI addresses space = Internet and
RC1918 = private LAN. Again an assumption that is not always true.)
I can also think of other tunnel encapsulation technologies like IPv6
IPSec over blah (Microsoft directAccess), IPv6 over GRE over blah, 6rd,
IP-HTTPS .....
I now understand the workaround for my specific ISATAP case: to encode
each ISATAP prefix individually in the prefix table. Thanks.
First follow up question on implementation detail: Do you think this
solution will be sufficiently scalable for larger environments? e.g. If
there were 200+ ISATAP routers. I'm not sure the prefix policy table
would still work efficiently if it had to be scanned before every
session start up. Maybe it would. I don't know. Do you have some
operational experience on the limits? Or is this way out of scope of the WG?
I also recognize that requirements will probably change over time.
Second more generic follow up question: Your draft suggests that RFC
1918 IPv4 addresses should now be considered global. I have read that
some earlier implementations consider them local. There are arguments
for both views.
So even if the ISATAP (global) IPv6 range was encoded with a lower
priority than IPv4 in an old implementation, my understanding is that
Rule 2 of source selection in RFC3484 would over ride that and prefer an
IPv6 address. So the prefix table would effectively be ignored in this case.
RFC3484 bis clarifies (and "fixes") this by suggesting that RFC 1918
address is global. That works for my use case today. But is this future
proof?
I think that this assumes that RFC1918 addresses are also connected to
the global IPv4 internet via NAT.
I realise that this again is probably a no-win case. Corporations who
have implemented RFC 1918+ NAT probably can consider RFC1918 to be
equivalent to global. But one day we may very well end up with islands
of IPv4 connectivity in an IPv6 global Internet, with RFC1918 once again
reverting to local scope.
Similarly there's a debate about whether to deprecate the 6to4 address
range in
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-02.
(perhaps including a phase out plan so there might be no one universal
set date for all network operators). One way of achieving that is
reducing the preference. Another is hard coding 6to4 as "deprecated." A
third would be to make detecting an address as deprecated a user
configurable setting with a default (thus allowing the flexible roll out
date).
In the ISATAP use case, I guess I was hoping for a single setting based
on selecting preference by "encapsulation type=ISATAP" with address
range = "don't care" that could be rolled out to all nodes, rather than
adding multiple address prefix ranges. This may or may not be
operationally practicable within the existing structure of RFC3484.
Are these examples adding up to an argument that the RFC 3484 bis
mechanism needs some sort of extension to allow network managers
themselves to make more of the changes via configuration, rather than
via code? Considering that different groups will take different
transition paths at different times?
I understand of course there is a balance to be struck somewhere, and
not everything can be configuration.
I also don't want to derail your work (which as I am already on record
as stating is very positive), but maybe you might like to consider a
restructuring of the (notional) RFC3484 bis table(s) to include not only
the prefix in the address selection table, but also to cover perhaps the
other different address "types" identified in section 3 of RFC3484:
i) whether an address range is deprecated [rfc3484 rule 3 of destination
selection]
ii) the encapsulation method that would be used with this address, 6to4,
native, ISATAP, IPSec, blah [rfc3484 rule 7 destination address]
iii) the scope classification for a range as interface-local,
link-local, admin-local, site-local, organization-local or global
[RFC3484 rule 2 source address]
......
to make the selection rules more configurable, whilst keeping the rules
themselves invariant.
One way of achieving this might be to specify that the prefix policy
table may have an additional columns which is by default "don't care"
and which could be expanded later to include the exceptions/ difficult
cases. Or that the single prefix policy table is augmented by additional
policy tables to cover the classification of the other address "types"
e.g. a (notional) table that translates prefix range to scope.
Maybe this is just a completely new piece of work / RFC. Maybe these are
such an off the wall cases that you decide that it isn't worth
investigating further at this time. I leave that choice to you. But I do
have a feeling that it could help future proof the implementations and
give more granularity to individual network managers to implement
RFC3484 bis table contents as they see fit, whilst still allowing the
IETF WG to suggest useful defaults.
The bottom line I guess is whether you are convinced that all potential
use cases for the coming X years are already covered.
Once again, thanks for your efforts.
regards,
RayH
Arifumi Matsumoto wrote:
Or, RFC3484's flexibility to prefer/de-prefer ISATAP ?
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
