Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Mon, Oct 11, 2004 at 02:14:26PM +0300, Pekka Savola wrote:
> 
> substantial
> -----------
>  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?

I think the doc needs to clarify 
a) why the cases that are being focused on are being focused on
b) show that no corner cases are being overlooked that may require additional
   transition functionality not yet available.

>  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 ?

A full matrix of posisbilities is big :)
 
>  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. 

On the contrary I think 4-in-6 tunnelling must be considered now.  It is
the end-game for some, for others it's on the near term radar.  But more
importantly it would be nice to have solutions that cater for both from
the outset, rather than discovering something in 2-3 years that we could
have thought about now.

> 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?

Remote access doesn't imply VPN for everyone.  My view on 4.5 and 7.5.2 is
providing IPv6 access in general, i.e. where the user's point-of-attachment
ISP offers no IPv6 service, but the user's home ISP (enterprise) can (e.g.
a broker or 6to4 relay).

> (Section 4.5 is not clear whether you're addressing the 'branch office' or
> 'home user' case.. probably the latter?)

By "site" I'd include branch offices.  For 4.5 I mean a user at home, or
a hotspot, or any case as per my text immediately above.
 
> 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].

Hmm, I don't remember writing that, good spot :)  I suggest removing the
reference to ULAs in 7.3.2.

> 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.
> 
> ==> 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.

OK, so say

"The enterprise site should deploy a DNS service that is capable of
 serving IPv6 DNS records (of the AAAA format, see RFC????) to facilitate
 DNS lookups of IPv6 addresses for nodes.   Where IPv6-only nodes are
 deployed on site, the DNS server(s) should be capable of communicating 
 over IPv6 transport.  It is thus prudent that the site's DNS servers
 should be planned to be dual-stack."

> (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.

OK, well, we run local dual-stack resolvers, and also put these in the
global DNS.   We're deploying dual-stack to facilitate the easy deployment
of IPv6 only nodes in due course.

> 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..

So "An IPv6-only stateless configured..."

Also we should state (if the ent team agrees) that a goal of dual-stack
everywhere (Sect.4) is to prepare for v6 only devices to be added easily,
thus all key services (DNS, NTP, etc) should be available over v6 transport.
 
> 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?]

I think we could integrate Appendix B's thinking into the main text?  But
that's a big chunk of work... 
 
> ==> 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.

Right, but the ISP analysis also focuses on L3, as does unmanaged, and they
have a similar title?

This is also why we consider L3 and only basic services (DNS), and not VPNs
etc in the doc.
 
> 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) ?

In 7.4.
 
>  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.'

The above line was only ever meant to be such a thing, so any wording is OK
as long as it makes the point clear.
 
>  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...

It is a currently valid RFC that should be considered in host address
configuration, hence it's in 7.4.3.
 
> 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?

I agree it should be included.  Not sure on exact wording.
 
>  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.

Yes, manually configured.  We do this now and it is used.   Up to the user
to choose that (or whoever admins their machine) or to use a "near" relay
offered by some other ISP.
 
> ==> 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?

Good point :) 
 
Thanks for the feedback!

-- 
Tim