[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)
Inline,
(I've removed discussions on which no further comments seemed
necessary)
On Tue, 12 Oct 2004, Bound, Jim wrote:
> > 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?
>
> We need to add more text to sect 3 and 8. If trivial but pivotal to the
> analysis we kept them in the draft for later context and why we have
> more writing to do.
Yes, it makes sense to keep the important cases even if they were
trivial. But my nit was just on the wording, which said that trivial
cases were already removed.. it shouldn't have said that, or it should
have been more exact in describing what actually was removed (and why
exactly).
> > 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).
>
> I think we can enhance that text but don't think it wise to discuss that
> which is omitted because that can cause a rathole. Would suggest that
> WG tell us what needs to be added?
I see a problem with not discussion the omitted ones at all. You've
been through the though exercise of going through all the
combinations, and using some methodology, picked the ones that you
felt were interesting. I think that methodology needs to be carefully
described because otherwise the people who might have different
assumptions than you (on what they consider important or not) probably
arrive in a different result.
What I'd like to see is the clear "derivation" of the table, in a
sense as a mathematical proof is derived. Each step can be reasonably
easily understood, and by following the steps, the correctness of the
final result can be evaluated.
> > Please also remember that even the trivial tunneling/translation
> > scenarios will need to be described if we need a (new) solution to
> > them.
>
> We believe we have that covered.
>
> What do you mean by new solution that may help?
Sorry, I don't understand your question.
> > 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 ?
>
> We do that by the protocol in the cell but we can explain that better
> for further input to see if WG believes it is correct. Seems we need to
> describe the cells better from recent input.
OK.
> > 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?
>
> I would agree on v6 only ISPs and that really is dual stack for some
> time.
>
> But we as a team and many in this WG do believe IPv6 dominant networks
> will be supported and we intend to leave that scenario and matrix cell
> in the spec but we can keep discussing.
>
> We do need to make it clear an ISP will not be v6 only that was not our
> intention either.
My main concern was on v6 ISPs, though I'd be a bit concerned of the
v6-only -> v4-only app scenario. That would seem to be like generic
v6-only + NAT-PT direction, which folks may or may not agree with.
But that can certainly be discussed.
> > [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]
>
> V6only apps implies a dual stack. It should say v6 apps.
Not sure if I understood your comment. I was saying that there are
different cases like:
1) all the applications on a node are IPv6-only, and the node is
IPv6-only, with only v6 network connectivity
2) all the applications on a node are IPv6-only, and the node is
dual-stack
3) some apps on a node are v6, some v4, and some dual-stack; the node
is dual-stack, with v4 connectivity through tunnel or natively
I am rather concerned about the usefulness of 1) having to talk to v4
hosts or apps (the NAT-PT model). 2) makes seemingly little sense for
the same reason, because if the nodes are dual-stack, why not have
some of the apps (at least) dual-stack or v4 as well? 3) makes most
sense of these particular examples.
> > (Section 4.5 is not clear whether you're addressing the 'branch
> > office' or 'home user' case.. probably the latter?)
>
> We are addressing the enterprise and enterprise remote sites. We need
> to make that clear this section is incomplete now. Most enterprises run
> their own Internet Walmart, GM, DOD, Renault, Boeing, etc and each will
> have different views and business reasons for deploying IPv6. Again
> one-size-does-not-fit-all.
Sure, but the point is that the doc should be consistent on what it
says it's covering (and what not). What actually is covered is a
separate issue.
> > 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.
>
> Not sure I agree. V4 or v6 transport is a choice we assume dual stacks?
I meant, v6 transport for DNS is not required when you run dual-stack.
It's nice, of course, but not required. It's only required with
v6-only.
>
> > 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)
>
> I think first we need to provide support for all possibilities and we
> cannot require users to deploy our view, only provide mechanisms for
> scenarios we believe we have heard. And there are enough users want to
> run IPv6 dominant subnets immediately and this does not mean nor to we
> imply v6 only anything if so we need to fix it.
>
> We should not be doing business cases for IPv6 in the IETF. That is
> what will determine how transition is done in the market. Out of scope
> for the IETF.
Sure, but the doc should probably include some analysis on what each
approach implies.
> > | 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?
>
> We can do that but point is decap via Tunnel Broker at remote site is
> something we have heard. I agree with all the security concerns when
> Enterprise is going to public Internet.
Yes -- so if these are described, these issues should probably be
described at some length, because this is a non-trivial approach and
fundamentally requires some kind of association with Net1 and Net2,
which may not be valid in some cases where this comes up.
> > |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 ?
>
> We have heard it is a requirement and it is an option.
Same argument as above.
> > | 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?
>
> No DSTM just provides address on the link or subnet. Nomenclature
> positioning needs work.
This is probably a moot point due to the bug below.
> > 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 ?
>
> This is a bug. The v4 is encaped in v6 to the edge, and we can define
> the edge better.
>
> Good catch.
OK.
> > 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..?
>
> Not really it is an example of a real network reinforcing the enterprise
> and the objective of the appendix.
Not sure if I understand your comment. The text might perhaps be
better placed & expanded in a separate doc (like Tim Chown's campus
transition), or maybe some parts generalized in the body..
[...]
> > 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?
>
> All of the above have to be part of our analysis but how we present that
> is TBD.
OK great.
> > 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?
>
> Hmmmm to some degree yes but we don't want to own that one in this spec
> we may need some WG help on this one.
Well, at least it could be noted as an open issue, even if nothing
concrete is done or decided in this document. (In any case, this doc
should not give "normative" guidance on which way to go, because we'll
likely need IETF process to run on this).
> > 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.
>
> I want to fight for an exception on this ok. So I will get ready to
> ask. I understand but these folks names all should be listed.
I think exceptions are only rarely granted, but of course, this is a
moot point before this ready to the IESG.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings