[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)
Hi,
On Thu, 7 Oct 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote:
> your proposal sounds like a plan. If the WG decides to remain silent
> until next week, please produce another draft without comments. I guess,
> the WG will speak up sooner or later!
I had been waiting for comments from the WG participants, but we
haven't yet had much much of that..
Below are my personal comments. I agree that the document needs to
continue spinning forward. There are many issues that still need
fleshing out even under this restricted applicability.
In short, I think the doc is a good start, but obviously as all
initial documents, can always find a room for improvement. Hopefully
my comments below help in that.
substantial
-----------
1)
1.a) the matrix in section 3 (and sect 8) appears to be out of sync from the
description of section 3 (see below for 'v6 to v4'), for example because the
text says trivial scenarios have been removed, but matrix lines 1,2,12, and 13
(at least) are extremely trivial. What has happened?
1.b) Further than that, one thing I'd like to see is slightly more text (if
that's not too difficult to manage) describing as precisely as reasonable
how the table has been 'derived', in a manner that the reader would be able
to follow which combinations have been omitted and due to what reasons.
That would allow one to better analyze that all the cases have been dealt
with (in one manner or another).
Please also remember that even the trivial tunneling/translation scenarios
will need to be described if we need a (new) solution to them.
1.c) you may need to end up having to define the columns of the matrix
carefully. In particular 'Host X network' (I read it as "the enterprise
network originating the packets") has at least one ambiguity. How do you
represent the fact that the first-hop link of a dual-stack node supports
only one protocol version, but further down the enterprise network both
protocols are supported ?
1.d) there also seem to be some scenarios which are either too far in
the future or easily worked around which might be decreed out of scope. For
the former, consider the cases of v6-only ISPs -- I don't think these are
worth the energy at this point of time. Or do you refer to *dual-stack*
ISPs who are offering only v6 services (and provide translation/tunneling
for v4 legacy)? For the latter, consider the scenario 4, i.e.,
v6-only application run on a dual-stack host, towards an IPv4-only
application. I mean, what would the point of creating v6-only application
which needs to talk to v4-only application, because doing such would nullify
all the benefits of IPv6 -- couldn't one just say that one should do a
dual-stack app in that case?
[IMHO, v6-only apps should never be used if that necessitated the
translation to v4, because doing so would nullify the usefulness of v6-only
app to begin with, or requiring embedding a lot of v4 hacks in the
translator -- both would seem like non-starters to me]
2) section 4.5 and 7.5.2 describe some approaches to remote IPv6 access
support, but Introduction ruled IPv6 VPN's as out of scope. These could be
seen as contradictory (but maybe the latter referred to v6-in-v6 VPNs, I
don't know).. maybe it needs to be clarified what's in scope and what's not?
(Section 4.5 is not clear whether you're addressing the 'branch office' or
'home user' case.. probably the latter?)
3) section 4.1 says that ULAs are not considered or advocated in this doc,
while 7.3.2 says they should not be used. These appear to be conflicting
statements. I think it'd be useful to mention ULAs, state that they are not
*necessary* but could be used under specific conditions, and possibly to
point to another document to come [on NAT-PT/RFC1918 alternatives].
4)
7.4.1 IPv6 DNS
The enterprise site should deploy a DNS service that is capable of
both serving IPv6 DNS records (of the AAAA format, see RFC????) and
of communicating over IPv6 transport.
Specific IPv6 DNS issues are reported in [DNSV6].
==> I think it would be useful to make it clearer here that while the v6
transport is nice, it's in no way requirement for anything, except for
deploying v6-only nodes.
(For example, in our enterprises, we haven't been able to field v6 transport
resolver support in 2-3 years due to a number of reasons, but that hasn't
stopped us from deploying v6 -- the document should (IMHO) give as few as
possible requirements for "moving forward" with IPv6.
The similar occurs in 7.4.3:
A stateless configured node wishing to gain other configuration
information (e.g. DNS, NTP servers) will likely need a Stateless
DHCPv6 service available.
, where this doesn't clearly identify that these are not strictly necessary
for dual-stack systems.. because they are already configured using v4
protocols and means. Just to make it clearer that these are not a strict
requirement for v6 deployment..
5) a few further comments on the matrix in section 8:
======================================================================
| IPv6 | | | | IPv6 |IPv6 Host Tunnel
3 | ---- | IPv4 |Dual IP |Dual IP| ---- |(Brokered atISP)
| Dual | | | | IPv6 |
==> isn't this a conflict with this statement in Introduction:
We are also assuming that the enterprise deployment is one being
undertaken by the network administration team, i.e. this document
is not discussing the case of an individual user gaining IPv6
connectivity (to some external IPv6 provider) from within an
enterprise network.
(i.e., it seems as if there is zero v6 support in the home enterprise, so
the host gets it from the ISP-- but this was considered out of scope...)
| IPv6 | | | |IPv4 IPv4|Translation on
4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----|local IPv6
| Dual | | | |IPv4 Dual|domain
==> as said, IMHO this nullifies the usefulness of creating v6-only
applications so wouldn't it be better to just require such apps to support
v4 as well? (there may be a couple of rare exceptions to this, like 3GPP
IMS, but those are another story)
| IPv6 | | | | IPv6 |IPv6 Host Tunnel
5 | ---- | IPv4 | IPv4 |Dual IP| ---- |(Brokered at
| Dual | | | | IPv6 |Net2)
==> this would appear to be case where the host tunnel is brokered across
the Internet. What reason would Net2 have for providing this to other
enterprises? Do you have specific assumptions about their relations?
|IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Site-to-Site
6 |---- or ----| or | IPv4 | or |---- or ----|Tunnel|
|IPv6 Dual|v6 only| |v6 only|IPv6 Dual|(Brokered?)
==> wouldn't this be creating something like 'v6 6bone mess' (especially if
sites are 'v6 only', which we all probably want to avoid? I mean, is there
a specific problem in the current approach, i.e., the enterprises which want
to connect other v6 enterprises to get v6 ISPs which are globally connected
throughout the Internet ?
| IPv6 |Dual IP| IPv4, | | IPv4 |Translation on
7 | ---- | or | IPv6 or| IPv4 | ---- |local IPv6
| IPv6 |v6 only|Dual IP | | IPv4 |domain
==> isn't this a regular 'why don't you just run dual-stack instead' argument ?
| Dual | | | | IPv4 |DSTM for
10| ---- |Dual IP| v6 Only| IPv4 | ---- |v4 thru v6
| Dual | | | | IPv4 |
======================================================================
| Dual | | | | IPv4 |DSTM for
11| ---- |v6 only| v6 only| IPv4 | ---- |v4 thru v6
| Dual | | | | IPv4 |
==> you are proposing to run DSTM over Internet, right? I don't think
it was ever (except for separate DSTM VPN I-D) designed to run like
that, and it would likely have significant amount of security issues.
I also don't see the element in the middle which would support
dual-stack?!? i.e., how does v6 only site talk through v6-only ISP to
a v4-only site, for example? Also, (repeating from matrix line 5
above), what would be the justification for Net2 to provide such
Interdomain service ?
6) I'm having slight problems, at least yet, at seeing what is the role of
appendix B in this document. This seems to be partially duplicating the
text from enterprise scenarios, or..? It also has some specific discussion
and good analysis. Should some parts of this be in the body, in a separate
document, or..? [also note, the text is rather unreadable because some
lines are wrapped oddly -- are you using good tools e.g. xml2rfc for
editing?]
semi-substantial
----------------
IPv6 Enterprise Network Analysis
==> given that the document restricts itself to (mainly) L3 considerations,
would there be simple ways to try to reflect that somehow in the title of
the draft and intro/abstract? For example insert 'connectivity' there? Not
a big issue.
==> s/Analysis/Transition Analysis/ ?
Abstract and introduction say:
This document analyzes the transition to IPv6 in enterprise
networks.
==> should one say "to using IPv6" instead, given that the focus of the
document is not go all the way to the get to IPv6(-only), but the first step
being providing the IPv6 capability?
...
As an example, Scenario 1 is an IPv6 application trying to
establish a communications exchange with a destination v4 only
application.
==> uhh?? Not by the matrix at least -- maybe some matrix lines were
removed? (see also substantial issue 1 above)
Then, the IPv6
intranet communication will not be efficient, as it will require
all the traffic to be forwarded by the IPv4 infrastructure to the
Tunnel-End-Point located at the ISP. This could be acceptable if
the IPv6 applications do not require intranet communication at all,
for example in the case the application server that is located
outside of the enterprise network, or in other networks of the same
enterprise.
==> this section discusses only efficiency (AFAICS), but a major factor
whether to pass internal traffic to the ISP (and back) is about trust. For
most enterprises I know (and all the big ones, I'd suspect), they don't want
to give external folks any chance of intercepting internal communications,
which might or might not be encrypted, and might or might not contain
classified information.
If the tunnel end-point is at the ISP, there is no way to prevent this.
Thus I can imagine no scenario, where an enterprise (which would have more
than a couple of employees, or operate w/ encryption) would want to put the
end-point out of it's own trusted network.
This also becomes an issues of redundancy; if the communications to the ISP
breaks down e.g., temporarily, is the internal traffic affected? Having
internal tunnel endpoint would ensure that one would be able to continue
without disruptions.
........
5.2 Manual versus Autoconfigured
If the number of nodes to be using IPv6 is reduced, an option is to
use statically configured tunnels.
However, in general automatic configured tunnels will be preferred.
Section 5 doesn't yet discuss pros and cons of connecting sparse
nodes, nor management/security issues. We need to add that in -01.
==> this isn't complete yet, so I don't know if you intended to discuss
these or not but here are a couple of potential considerations:
- are you considering just autoconfigured set-up ('assisted tunneling' or
'zero-conf tunneling'), or also "direct tunneling" ?
- are you considering whether there are internal NATs in the enterprise or
not (I don't personally know whether this is typical or not) ?
- do you consider whether there are multiple boxes or just one (and if
multiple, how are would they be distributed [e.g., geographically])
i.e., the number of users?
.......
7.4 Phase 2: Deploying generic basic service components
Most of these are discussed in Section 4 of [BSCN]. Here we
comment on those aspects that we believe are in scope for this
analysis document. Thus we have not included network management,
multihoming, multicast or application transition analysis here, but
these aspects should be addressed in Phase 2.
==> I may be misunderstanding the last line, but isn't that saying that
section 7.4 should be addressing this, or are you referring to the "next
round" of enterprise evaluation (beyond the basic concepts) ?
...........
....
For secure autoconfiguration, the SEND protocol is defined (now at
RFC????).
==> because deploying SEND is not necessarily quite as trivial as this,
maybe a placeholder should be put here, like 'The best practices for
deploying the necessary certificates need to be analyzed.'
........
Hosts may also generate or request IPv6 Privacy Addresses
(RFC3041); there is support for DHCPv6 to assign privacy addresses
to nodes in managed environments.
==> is there actually any justification for using RFC3041 in enterprise
environments? Should one put such a doubt here if not? Personally, I'm
having trouble figuring out the actual problem...
....
Use of [NAT-PT] is discouraged [cite the I-D on this?]. A
recommended solution is the use of ALGs. Many applications
naturally have an ALG behavior, and can be used to offer access for
"legacy" IPv4 services such as SMTP (dual-stack email server, see
[cite I-D, by Alain I think?]) or HTTP (a dual-stack web cache),
and are already operated by many enterprise sites. By dual-stacking
the servers, an IPv6 only node can reach an external IPv4-only web
site (for example) via the proxy without any additional (Layer 3 or
4) translation being required.
==> it would be worth mentioning (at least as a problem, if not further
discussed) in a new paragraph how one would configure such proxies or
translators on the v6-only nodes. Manually? Using yet-to-be-defined DHCPv6
options? Using unspecified means?
Such an aid may be either a tunnel broker [TBRK], ideally one that
supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If
a 6to4 relay is offered, the site should be aware of security
issues with operating 6to4 relays [cite ref?].
==> are you referring to the 6to4 relay usage in a manner where the
enterprise would provide a 'private' 6to4 relay, just for its own users who
would need to know its v4 address, and manually configure it on their
laptops (w/ using public addresses)? Note that there is no provision for
access control here. Considering how common the NATs are, this seems like
something that doesn't have sufficient "return value" for the enterprise,
considering that there are plenty of free relays reachable through the
anycast prefix.
There is ongoing work on auto-transition and assisted tunneling
tools that may also be applicable as remote access aids [cite
refs?].
==> possibly, but please note that most of those focus on the scenario where
the access is provided by the first-hop ISP. What you're looking for is
something like assited tunneling registered mode ('TSP') or v6-supporting
L2TP (which is not a necessarily a big problem, as PPP supports v6
trivially).
procedural
----------
==> there is one author too many (6 > 5). If it is not possible to reduce
the number of authors, the alternative would be just listing the editor in
the front page, and the authors in the contact information or contributors.
==> there are a lot of documents in 'normative references'. These are meant
to be documents which are required to be read to understand the document.
Please note that this doc cannot be published until all of these are also
published. Is that intentional? Maybe some shuffling around would be
warranted?
editorial
---------
==> there are quite a few references with 'RFC????' or the like -- these
should be filled in (naturally ;-), and maybe put in as informative
references explicitly. (Also a mention of I-D in 7.4.6, that would be
draft-motonori-dualstack-smtp-requirement-01.txt)
==> Introduction and Abstract use the term 'Provider' before it's defined,
and as such, it isn't clear to the reader that you refer to the ISP with it.
Two possible fixes:
1) rename Provider to ISP (because the terminology requires providing connectivity
in any case, so this looks pretty close to ISP to me), or
2) expand Provider to ISP in abstract/introduction.
...
The audience for this document is the enterprise network team
considering deployment of IPv6. The document will be useful for
enterprise teams that will have to determine the IPv6 transition
strategy for their enterprise.
==> there appears to be some overlap with these sentences ?
The enterprise analysis will begin by describing a matrix tool to
be used to portray the different IPv4 and IPv6 possibilities for
deployment. The first column (Application/Host 1 OS) represents the
IP-capability offered by the node that originates IP packets. The
second to last column (Application/Host 2 OS) represents the IP-
capability offered by the node that terminates the IP packet. In
between are three columns that represent the IP-capability of
typical networks traversed by the packet, including an originating
host network (Host 1 Network),Service Provider Network and
Destination Host Network (Host 2 Network). Each row (1 through 13)
is one possible scenario and the final column shows the recommended
transition mechanism to use for that particular scenario.
==> in the matrix in section 3, there it's the last column. (This also
applies in the text in section 3)
==> actually, I think the discussion here is slightly out of place, as it's
already there in section 3 (where it's better placed). I'd consider just
summarizing this paragraph here to one or two sentences, and referring to
fuller description in section 3.
IPv6 only - A node or network capable of supporting only
IPv6. This does not imply an IPv6 only
stack, in this document.
==> I find the last sentence slightly confusing, maybe it would better read
like 'In this document, a dual-stack node which has disabled IPv4 stack is
also considered IPv6 only.'
Many router platforms can tag multiple VLAN IDs on a single physical
interface based on the subnet/link the packet is destined for
==> 'Many' ? Are there platforms which *can't* do it? I'd be surprised :).
Maybe just remove 'Many' or replace with 'Practically all'.
The parallel infrastructure would only ever be seen as an interim
step towards a full dual-stack deployment on a unified
infrastructure.
==> could 'would only ever be seen' be reworded? That seems like a complex
structure of words for us foreigners..
The upstream provider could have already deployed some IPv6
service, either native IPv6 in its backbone or in the access
network, or a combination of both. Also, or alternatively, could
have deployed one or several transition mechanisms based upon
tunnels, for example in the case where the access network doesn't
support IPv6. In this case, the enterprise could decide to use
those available transition services from the ISP. However, this
will usually mean that the each of the different nodes in the
network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6
intranet communication will not be efficient, as it will require
all the traffic to be forwarded by the IPv4 infrastructure to the
Tunnel-End-Point located at the ISP. This could be acceptable if
the IPv6 applications do not require intranet communication at all,
for example in the case the application server that is located
outside of the enterprise network, or in other networks of the same
enterprise.
==> s/could/it could/ ?
==> could this paragraph be broken into two (or three), making it more
digestible? :-)
The enterprise could also decide to deploy its own transition box
and possibly collocate it adjacent to the border router that
==> s/collo/co-lo/
IPv6 communications between IPv6 nodes will use IPv6 to
communicate.
==> sounds like a no-op ?
Author's Address
==> make that "Authors' Addresses" ;-)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings