[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-ietf-v6ops-ent-scenarios-00
Hi Tim,
Thanks for your hard work and thorough read of the specs and good input
to the work.
> Here are some (long) comments on draft 00. I am sorry they
> are later than
> ideal but I hope they are still useful prior to Minneapolis.
Very useful.
>
> The document is absolutely on the right track, in my view.
> The detail of comments is mainly for clarification :)
The team thanks you for that comment.
>
> The introduction generally reads very well and sets the scene nicely.
Thanks.
>
> > Each enterprise will select the transition that best
> supports their
> > business requirements. Any attempt to define a default
> or one-size-
> > fits-all transition scenario, will simply not work. This document
> > does not try to depict the drivers for adoption of IPv6 by an
> > Enterprise.
>
> OK, so the next paragraph shouldn't mention drivers = motivations:
Good catch.
>
> > While it is difficult to quantify all the potential
> motivations for
>
> s/motivations/scenarios
yep.
>
> > enterprise network teams to move to IPv6, there are some
> cases where
> > an abstract description is possible. The document presents three
> > example motivations as a general use case. This model
> can be used to
>
> s/motivations/base scenarios
yep.
>
> > define additional abstractions, for the Enterprise to define
> > scenarios to fit their requirements.
>
> s/scenarios/specific scenarios
excellent.
>
> > The first scenario assumes the Enterprise decides to
> deploy IPv6 in
> > parallel with IPv4. The second scenario assumes the Enterprise
> > decides to deploy IPv6 because of a specific set of
> applications the
> > Enterprise wants to use over an IPv6 network. The third scenario
> > assumes an Enterprise is building a new network or
> re-structuring an
> > existing network and decides to deploy IPv6. The document then
> > defines a set of characteristics that must be analyzed.
> The document
> > then provides several scenario examples using the
> characteristics
> > to
>
> s/several/three specific
Yep.
>
> > depict the requirements. These are common Enterprise
> deployment cases
> > to depict the challenges for the Enterprise to
> transition a network
> > to IPv6.
>
> I think one "danger" we have here is that by generalising as
> we do later down the text, that the requirements become so
> generalised that the analysis can
> apply any mechanism to any scenario :) I'm not sure whether that is
> a real (or important) concern.
I think it is an important concern and the hope is we fine tune the
generalizations to be specific enough to keep a focused effort for the
analysis.
>
> > The interoperation with legacy functions within the
> Enterprise will
> > be required for all transition except possibly by a new
> network that
> > will be IPv6 from inception. The network infrastructure
> components
>
> Well, not maybe for scenario 2 below, because we are adding
> IPv6 for a specific application (let's say a specific IPv6
> p2p app like Napster6 :) and in that case we don't care to
> access legacy networks, as we are purely interested in the v6
> app, as the scenario states.
This is good point about secenario 2 and good catch.
>
> > will inform the Enterprise of key points of transition in their
> > networks that require consideration for IPv6 deployment and
> > transition.
>
> I think "point of transition" is ambiguous - so see below we
> should define what you mean.
Agreed in next release we will remove all references of "point of
transition" it is here now to get folks to think points of transition
and now its time to define them I personally agree with you.
>
> > Using the scenarios, characteristics, and examples in
> the document an
> > Enterprise can define a scenario. Understanding the
> legacy functions
> > and network infrastructure components required, the
> Enterprise can
> > determine the network operations required to deploy
> IPv6. The tools
>
> The wording is confusing here: "using a scenario to define a
> scenario", so we need to write something else... do we mean:
>
> Using the base scenarios, characteristics, and examples
> in the document
> an Enterprise can define its specific scenario requirements.
Yes much better.
>
> > Enterprise Network - An Enterprise Network is a
> network that has
> > multiple links, a router connection to a
> > Provider, and is actively managed by a
> > network operations entity.
>
> s/multiple/multiple internal
Yes.
>
> s/a router connection/one or more router connections
> s/a Provider/one or more Providers
> (since you mention multihoming in characteristics below)
Yes.
>
> Should we define "point of transition" and "characteristic"?
> I think it would help. Still a nice short set of definitions :)
I think point of trasition for a spec is going give us trouble but I do
think defining characteristic is good idea.
>
> > Three base scenarios are defined to capture the
> essential abstraction
> > set for the Enterprise. Each scenario has assumptions and
> > requirements. This is not an exhaustive set of
> scenarios, but a base
> > set of general cases.
>
> We might add another base scenario in Minneapolis but we must
> ensure that any such addition really adds value so we keep
> the doc as simple as possible.
This has 100% consensus by the team. I agree.
>
> > 3.1 Base Scenarios Defined
> >
> > Scenario 1: Enterprise with an existing IPv4 network
> wants to deploy
> > IPv6 in parallel with their IPv4 network.
> >
> > **Note To V6ops WG: Would a network topology map be useful here?
>
> I don't think such a map is necessary for any of the base scenarios.
Thanks for that input.
>
> However, by "in parallel" do you mean dual-stack
> infrastructure or separate
> infrastructure, or is that irrelevant?
I think we need to explain what we mean in next release. But some nodes
will be dual stack and some nodes will be IPv4. I don't think to many
will be IPv6 only.
>
> > Assumptions: The IPv4 characteristics have an equivalent in
> > IPv6.
>
> Where might they not do?
I just wrote this one down as it came from last input. I think we need
to discuss what this means as a team and be great if our WG colleagues
would jump in on this specific too. I think it is vague and unclear.
IPv6 will have functions that do not exist in IPv4 as one example.
>
> > Requirements: Don't break IPv4 network characteristics
> > assumptions with IPv6. IPv6 should be
> equivalent or
> > "better" than the ones in IPv4, however, it is
> > understood that IPv6 is not required to
> solve every
> > single problem.
>
> Maybe this could say "that IPv6 functionality may not be
> required, or feasible to deploy, on all parts of the
> Enterprise's infrastructure" ?
Yes I like this much better. Note again I just copied this from input.
So we may have to have some discussion but I support your suggestion.
>
> > Scenario 2: Enterprise with an existing IPv4 network
> wants to deploy a
> > set of particular IPv6 "applications"
> (application is
> > voluntarily loosely defined here, e.g. peer
> to peer).
> > The IPv6 deployment is limited to the
> minimum required to
> > operate this set of applications.
> >
> > Assumptions: IPv6 software/hardware components for the
> application
> > are available.
>
> Hmmm. If the reason is to deploy an IPv6 application (e.g.
> p2p VoIP) the solution will depend on whether the host is
> dual-stack (IPv4/IPv6) or
> IPv6(-only). Clarify, or does it not matter?
Well I cheated and admit it to all :---). Bringing IPv6 only into this
complicates the discussion and eventual consensus for this work. I
think in this case it does not matter in the node instance and the
network instance if the IPv6 packet is delivered. But, what it affects
is the transition mechanisms required if the node is IPv6 ONLY to speak
with legacy IPv6 nodes. That is the one area where translation is
required.
But does IPv6 only mean that the node simply does not have an IPv4 stack
at all. I don't see that happening for a long time. I suggest we
assume dual stack for this work and not IPv6 only. That for IPv6 ONLY a
future addendum to this spec be written?
What does the WG think about my suggestion above? Thanks.
>
> > Requirements: Don't break IPv4 network operations.
>
> That's always a requirement :) For "operations" read "functionality,
> operation or security" maybe, and probably more beyond.
Yep. But it was felt it needed to be said in the spec.
>
> > Scenario 3: Enterprise deploying a new network or
> re-structuring an
> > existing network, decides IPv6 is the basis
> for network
> > communication.
>
> Does this mean IPv6-only network infrastructure? Remember
> you have defined
> IPv6 above as equal to IPv6-only, so is that what you mean here?
>
> > Assumptions: Required IPv6 network components are available, or
> > available over some defined timeline.
>
> Again, do you really mean IPv6-only, or IPv6-capable?
IPv6 Capable. I need to fix that above ok.
>
> > Requirements: Interoperation and Coexistence with IPv4 network
> > operations and applications are required for
> > communications.
>
> So is scenario 3 an IPv6-only network into which IPv6-only or
> dual-stack hosts may be deployed? If so maybe state that 3
> paragraphs up.
IPv6 capable but will fix that above too. I want to start another
specific thread on this for the WG to discuss to from your input. Good
catch.
>
> I think the four sets of characteristics below are fine to
> cover the basic requirements.
Thanks.
>
> > Characteristic 1 - Providers for External Network Operation
> > - IPv4 existing address ownership (Provider based addresses vs.
> > Provider independent addresses)?
>
> And number of globally routable IPv4 addresses available?
Yes.
>
> > - Do ISPs offer IPv6 service?
>
> By service do you mean native service, or tunnelled, or any
> service...?
Any. But we should differentiate the two as it relates to what the
Enterprise can do.
>
> > Characteristic 3 - Enterprise IT Department Operations Analysis
> > - Is inter-site communications required?
>
> You have "one site vs multiple sites" in characteristic 1?
Will fix I figured providers as plural implied "multiple".
>
> > - External IPv4 routing protocols used?
>
> That one belongs in characteristic 1?
Yes.
>
> > - List of "network operation" software that may be
> impacted by IPv6?
> > - DNS
> > - Management (SNMP & ad-hoc tools)
> > - Enterprise Network Servers
> > - Mail Servers
> > - High Availability Software for Nodes
> > - Directory Services
>
> - Other services (NTP, others...?)
Lets add to the list but at some point we need to add at the end "etc..
etc..".
>
> > - Are all these software functions upgradeable to IPv6?
> > - If not upgradeable, then what are the workarounds?
>
> - If not upgradeable, can an equivalent upgradeable
> software function
> be substituted for the one that is not upgradeable?
> (e.g. a different
> directory service mechanism)
This I think is to be done in the analysis spec??????????
>
> > Characteristics 4 - Enterprise Network Management System
> > - Management of Transition Tools and Mechanisms?
>
> This is an important area the WG needs to take on board.
Yep. I think Management Scenarios could be its own spec?
>
> > - What new considerations does IPv6 create for Network
> > Management?
>
> Does this affect the transition tool analysis, e.g. if
> RFC3041 means that IP-based authentication is no longer
> possible? I guess it may affect a
> specific implementation of a security policy?
Yep. But what I was thinking here is what new problems does transition
introduce onto the network of the enterprise? That list would be useful
I think. Esp. in Ent Scenarios to feed Ent Analysis doc.
>
> > This section presents a set of Base Scenario Examples
> and is not an
> > exhaustive list of examples. These examples were
> selected to provide
> > further clarity of Base Scenarios within an Enterprise of a less
> > abstract nature.
>
> I think these are now Specific Scenario Examples not Base
> ones? The answering of the characteristics against the base
> scenarios higher up in the document leads to these specific examples?
Excellent. I knew this in the head but could not hit my fingers while
editing. Thanks.
>
> > A bank running a large ATM network supporting an order
> of magnitude
> > number of transactions per second, with access to a
> central database
> > on an external network from the ATM network:
>
> "An order of magnitude number of transactions" is missing a
> word or two :)
Well we don't have data to say numbers. Nor should we. We do need to
say this better I was as Editor taking liberty to get the point across
we need better wording yes. But trying to state hard facts is not good.
>
> > - External connectivity not required.
> > - Multiple sites connected by VPN.
> > - Multiple sites connected by Native IP protocol.
>
> Perhaps add that it may use Net10 addressing? We should not
> hide from the
> Net10/ANT issues for transitioning networks. We have the
> Hinden draft on the way, although this example probably uses
> RFC1918 but not NAT :)
Yes and was not hiding just missed it as I hate it so bad and needed the
reminder :--)
>
> > 4. Support for Legacy IPv4 Nodes and Applications
>
> s/Nodes/Nodes, Services ?
Yes.
>
> > The Enterprise network will have to support the
> coexistence of IPv6
> > and IPv4, to support legacy IPv4 applications and nodes. The
> > Enterprise user has the following choices for that coexistence to
> > consider today.
>
> Does this mean "of IPv6-only and IPv4-only"? This is what is
> implied by the definition of terms at the start of the
> document. Do we actually mean "IPv6-capable and
> IPv4-capable" or, in the language of the definitions,
> "IPv6, IPv4 and IPv4/IPv6" applications and nodes?
I will fix all this in the doc to relay IPv6 capable.
>
> > 4.3 IPv6 communicating with IPv4
> >
> > An IPv6 only node wants to communicate with an IPv4 only node.
>
> Note the node can be IPv4/IPv6 but the application may be
> IPv4, e.g. if the source code is lost or the language it is
> written in has no IPv6 API?
>
> So do we actually mean "node" or "application"? We probably
> mean "services
> or applications on a node" as RPC, NIS, SMTP etc are services.
Nope I was bringing out the case of an IPv6 stack only node. That
should be changed.
>
> > In cases where the IPv6 host cannot be a dual stack, in order to
> > continue support of communications with IPv4 nodes an IPv4/v6
> > translator is required. Introduction of such translator
> will prevent
> > usage of end-to-end security and application carrying embedded IP
> > addressing information.
>
> You could say the translator may be at the network, transport
> or application layer.
We can add that but for this "reference" model document I don't think it
matters?
>
> > **Note to V6ops WG: Should we discuss porting of
> applications too in
> > the legacy section?
>
> I think this is done in the "application aspects" draft fine
> already, i.e. in draft-shin-v6ops-application-transition-01.
I agree and we can point to this work too.
>
> > 5. Network Infrastructure Requirements
> >
> > The Enterprise will need to determine what network infrastructure
> > components require enhancements or to be added for deployment of
> > IPv6. This infrastructure will need to be analyzed and
> understood as
> > a critical resource to manage.
> >
> > 5.1 DNS
> >
> > DNS will now have to support both IPv4 and IPv6 DNS
> records and the
> > Enterprise will need to determine how the DNS is to be
> managed and
> > accessed, and secured.
> >
> > **Note to V6ops WG: Should we get into other DNS issues?
>
> There are three categories of issues I think, i.e.
>
> - standards: dns resolver discovery, 512-byte response format,
> reverse zone managemnt and dynamic dns
>
> - transport: root servsers, OS supporting native lookup,
> and whether the
> upstream ISPs filter the root space /48's
>
> - registry: registering domains with IPv6 DNS servers
Agree but is Enterprise Scenarios the only spec that needs to address
that what about Umanaged, 3GPP, or ISP docs?
>
> Also, do you have control over your own DNS?
This is important to state yes.
>
> And is it important that reverse DNS lookup works, e.g. for
> sendmail to verify sender hosts? If so reverse population of
> statelessly autoconfiguring will be needed, and 6to4 use will
> be problematic?
This is true for all scenario documents, is Enterprise work the only
spec that has to do this or do we need a generic DNS transition document
as Management etc...
>
> > 5.2 Routing
> >
> > IPv6/IPv4 routers should be monitored to ensure the router has
> > sufficient storage for both IPv6 and IPv4 route tables. Existing
> > network design principles to limit the number of routes in the
> > network, such as prefix aggregation, become more
> critical with the
> > addition of IPv6 to an existing IPv4 network.
> >
> > **Note to V6ops WG: Above is example of additional text
> we could add
> > to each component we list here. Are there other Routing issues?
>
> Other issues are whether the upstream provider supports IPv6
> natively or offers transition aids, e.g. 6to4, site tunnel broker.
Yes.
>
> > 5.3 Autoconfiguration
> >
> > IPv6 introduces the concept of stateless autoconfiguration in
> > addition to statefull autoconfiguration. The enterprise
> will have to
> > determine the best method of autoconfiguration, for
> their network.
> >
> > **Note to V6ops WG: Should we get into other autoconfiguration
> > issues?
>
> Will the enterprise need IPv6 prefix delegation?
I think so :--). But we should add that to the list too.
>
> Will it need DHCPv6 forwarding?
Do you mean relaying?
>
> > 5.4 Security
> >
> > Current existing mechanisms used for IPv4 to provide
> security need to
> > be supported for IPv6 within the Enterprise. IPv6
> should create no
> > new security concerns for IPv4.
> >
> > **Note to V6ops WG: Should we get into other security issues?
>
> I think Pekka's security draft could be cited:
> draft-savola-v6ops-security-overview-00
I want to not respond and need to do more in depth read of that spec. I
think being paranoid is not good :--) (no refelection on Pekka's
security draft I just think we live in a very dangerous world and thats
life. Trying to correct that to far is not worth the time and one is
better off to die :--)). Just kidding. I will reread Pekka's work.
>
> Issues include backdoors for tunnels, handling firewall
> policy for end-to-end encryption, dual-stack possibly adding
> complexity to analysis, and DoS relay type attacks (e.g. 6to4 relays).
Yes for sure.
>
> > 5.5 Applications
> >
> > Existing applications will need to be ported to support
> both IPv4 and
> > IPv6.
> >
> > **Note to V6ops WG: Should we get into other application issues?
>
> Not beyond the shin-v6ops draft.
Agreed.
>
> > 5.6 Network Management
> >
> > The addition of IPv6 and points of transition will need
> to be managed
> > by the Enterprise network operations center. This will
> affect many
> > components of the network and software required on nodes.
> >
> > **Note to V6ops WG: Should we get into other Management issues?
>
> Probably not.
I agree. But we proabably need a network management draft of its own.
>
> > 5.7 Address Planning
> >
> > The address space within the Enterprise will need to be
> defined and
> > coordinated with the routing topology of the Enterprise network.
> >
> > **Note to V6ops WG: Should we get into other Address Planning
> > issues?
>
> Would IPv4 and IPv6 subnets be congruent?
I think parallel is more correct?
>
> An advantage of IPv6 is that you are unlikely to ever need to
> resize the subnets (up or down).
ERRRRRRRRRRRRRRRRR. Need to think about that. One could blow the bits
to the left on a site boundary with sensors :--).
>
> Available IPv4 address space affects (for example) the DSTM
> pool, NAT-PT, etc.
Yes but that has to be in analysis but we should generically point to
all this list.
>
> Do we have address space independence from provider?
I don't believe this is true at all? We do not even more so with IPv6
and I don't like that quite frankly ...................
>
> > **Note to V6ops WG: What other components are we missing?
>
> Here are some additional possible components:
>
> 5.8 Multicast
>
> Both from routing aspects, but also things like MLDv1/2
> snooping to help avoid traffic flooding.
>
> If multicast is needed then some tools may not be useful,
> e.g. 6to4 (there was a draft on 6to4 and multicast, but it
> seemed to have died).
We should add this yes.
>
> 5.9 Service discovery mechanisms
>
> The infrastructure may need to support many of these because
> there is little harmonisation of techniques in various standards, e.g.
> - LDAP or NIS
> - Well-known names
> - Well-known addresses
> - IPv4 or IPv6 anycast
> - LLMNR
> - DHCPv6 (Lite)
> - SLP, etc
Yes.
>
>
> > 7. References
>
> Maybe the applications draft (see above) and Pekka's transition
> architectures doc? (draft-savola-v6ops-transarch-01) And
> his security
> doc: draft-savola-v6ops-security-overview-00 ?
Yes. But want to reread Pekka's security overview ok.
>
> There's also RFC1752 which we could either cite or state that we no
> longer use as a yardstick. It talked about transition goals like:
> - incremental upgrade (hosts not routers)
> - incremental deployment (routers)
> - easy addressing (use dual-stack)
> - low start-up costs (procure wisely so infra enabled)
Good point. Yes.
>
>
> Other general comments:
> -----------------------
>
> What about preference of use of IPv4 or IPv6?
Ouch. I fear a 1000 mail message debate. I suggest we avoid this and
leave scenarios for the enterprise to have that debate when they deploy.
OK.
>
> How do we handle the "NAT is our policy" sites?
We do need to add this as you stated above. But not get into email war.
>
> Are IPv6-specific features out of scope... e.g. privacy
> extensions which may impact policy implementations like
> (weak) IP-based authentication?
In the scenarios I think they are but will have to see once we start
analysis.
>
> What about remote IPv4 nodes wishing to access your site
> IPv6(-only) services? Do you deploy (say) NAT-PT yourself, or
> rely on the remote site to introduce
> its own tools? Maybe this is covered OK in 4.3, but we
> could explicitly
> expand on it.
We should have a reference in scenarios so this can be discussed in
analysis.
>
> What about use of existing "software functions" that may ease
> transition, e.g. if already using proxies like web, mail, etc
> already, or using VLANs?
Possibly a footnote. But we should stay within the charter expertise of
this IETF WG.
>
> We should capture general transition tool requirements
> somewhere, e.g. a site depends on handling 100,000 remote
> transactions per hour, then any proxies,
> translators, etc must be able to support that level.
Maybe for sure in scenarios as long as it does not point to or suggest
any specific mechanism ok.
thanks
/jim
>
>
> Tim
>
>