Re: draft-pouffary-v6ops-ent-v6net-01

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

A few casual comments on v6ops-ent from the European 6NET perspective
(international academic IPv6 testbed)

tim

   An Enterprise network for this document is a user network connected
   to an Internet Service Provider (ISP) or a Private Network Service
   Provider (PSNP), is actively managed by the users of that network,

- or rather the administrators of the network

   and has multiple independent networks within the Enterprise.  It may
   also have mobile IP users accessing the Enterprise Network within the
   Enterprise network, from the public Internet into the Enterprise, or
   from a private external Internet network.  An Enterprise could be a
   Fortune 100 company large business (e.g. Manufacturing, Financial,

- which may be geographically dispersed?

   Government) or a small office business (e.g. Law Firm, Stock
   Brokerage, Discrete Engineering Parts Supplier, Office of 30 users).

- or a university (typically 20,000 staff and students), perhaps spread out 
- across a town/city

      M7:  Single Stack IPv6 ONLY Nodes (no known implementations today)

- but nodes can be run ipv6-only, e.g. FreeBSD, Linux (the main missing piece
- is often IPv6 transport for client host DNS lookups).  This is being done
- in some WLAN networks.

   Each EN will need to select the method to best suit their business
   requirements. Any attempt to define a default or one-size-fits-all
   set of variables and methods for all ENs would result in failure.
   These methods are discussed in Section 6 of the document.

- are there other metrics for the transition tool requirements/evaluation
- of applicability?  For example the number of global v4 addresses available.

   These are the six scenarios that will be used in the document to
   drive the ENPTs, which will be determined by the transition
   variables, methods, and tools. This is an overview of each of the
   scenarios.

         Scenario #1

         A large (20,000+ node) enterprise has an existing IPv4 network and
         wishes to turn on IPv6 for an engineering development group of
         ~100 clients that exist at two geographic sites. Each engineering
         group is on its own switched subnet. The IPv6 clients need to
         communicate with each other, but still need access to IPv4 based
         services provided by the corporation. What needs to be done to
         enable this deployment and where?

- this is like a scenario we are considering in 6NET, where early testbeds 
- may exist in a campus, with perhaps also individuals scattered in the campus.
- the wording "IPv6 turned on" implies dual-stack in the "islands"?

         Scenario #2

         An enterprise decides to deploy wireless services across their
         network, and for reasons of geography and topology groups of access
         points end up on different subnets. To optimize their support for IP
         mobility, they choose to make this service IPv6-only, while to secure
         the air link they choose to have all connections use a VPN access
         technology. These mobile IPv6-only nodes will still need access to
         legacy IPv4-only applications.

- this is a possible university scenario for new WLAN services.  Although few
- people are running v6-only routing now, it will happen, and at that time we
- may still have dual-stack nodes with v4 apps (i.e. although it's putting the
- cart before the horse, I think this scenario is our reason to keep working
- on DSTM, where much good work has already been done).   It is also worth
- considering whether the IPv4-only devices are internal (e.g. printers, or
- access points that can only be managed over IPv4) or external (e.g. remote 
- POP mail servers). 

         Scenario #3

         A modest sized (<10,0000 nodes) multi-site enterprise has
         deployed IPv4-NAT with overlapping private address ranges between
         the sites. They are looking to improve productivity through a
         peer-to-peer conferencing application, that will need to work between
         sites. They are willing to update the operating systems running that
         application to support both IPv4 & IPv6, and over time will do the
         same for other services on the network. Which transition technologies
         are applicable initially as they begin using the application? What
         changes or additional technologies are applicable when the ISP for
         some, but not all sites, offers native IPv6 service? What transition
         technologies are applicable when all ISPs offer IPv6 services, but
         some of the internal nodes remain IPv4-only?

- wearing the 6NET hat again, it is unlikely that European universities run 
- NAT, except for smaller colleges who brought in external "consultants" to 
- advise and deploy IP services.   Note we need to understand here the scenario
- for a single site, in addition to merging sites, as there are competing 
- solutions.  Having said that, GEANT (and 6NET) are spreading east to 
- countries where v4 global space is not so available.

- i think that scenarios 4 and 5 are not primarily academic-oriented, so i
- won't comment on them.

         Scenario #6

         A new Enterprise network is being defined for a new Trucking Business
         that provides location based services for their Truck Fleet over a
         wide geography.  The network will grow to > 10,000 nodes, and the
         Truck Fleets and Account Teams will use Mobile devices to access
         the Enterpise network's data and services. In addition many employees
         will be able to telecommute and work from home.  There is no physical
         Enterprise network today, and the Enterprise network team for the
         business wants to build this new network with IPv6.

- teleworking and mobility between campuses apply to university scenarios, be
- it staff or students roaming on campus or requiring connectivity from home
- networks, or perhaps while visiting other universities.   A common access
- method is desirable here for roaming (see www.terena.nl/tech/mobility/).


6.3 M3: IPv6 NAT to Communicate with IPv4

      1. A DSN wants to communicate with a legacy ENAD IPv4 ONLY service
         or node.  EN policy is that IPv6 NAT should be used for this
         communications.

- It would be nice not to use the phrase "IPv6 NAT" :)  Some general translation
- mechanism is required, it may be at the network, transport or application
- layer (i.e. NAT-PT, TRT or ALG when we discuss solutions).  To me, IPv6 NAT
- suggests something else entirely, that we want to avoid.

      4. Others ????

- IPv4 nodes inside or outside the enterprise may wish to initiate connections
- to IPv6 services inside the enterprise.

   ***IMPORTANT Discussion for Design Team and Working Group*** Should
   we recommend the following to the working group in the next draft and
   discuss at the IETF Atlanta meeting with the working group the
   following:

      1. The EN Design Team highly recommends that ENs not adopt the policy
         in reference "1" above.

- When we come to solutions, yes, probably, but the scenarios document isn't
- the place to push policy recommendations, imo.

      2. IPv6 ONLY nodes should not be deployed in an EN until they will not
         require access to any legacy IPv4.  This means that applications
         and infrastructure has been ported or moved to IPv6.  Until that
         time nodes for transition should be DSNs.  This means ENs that
         want to use IPv6 ONLY nodes will be required to move applications
         and infrastructure to IPv6 first.

- but this cannot always be done.  I like to print stuff, but I prefer to use
- IPv6 for the bulk of my day-to-day routine.  Has anyone built a v6 network
- printer yet (even dual stack)?

   We also need to get industry input from IPv6 early adopters and those
   planning to move to IPv6 or in IPv6 test mode to note in this draft.
   It is imperative we get all input on this issue because it can mean
   avoiding NAT for IPv6 and the loss of end-2-end communications and
   security for the deployment of Next Generation Networks.

- I think everyone in 6NET deploying IPv6 now would want to avoid IPv6 NAT,
- but 6-6 NAT is a different animal to 6-4 or 4-6 NAT-PT.  ALGs can often
- provide a solution (e.g. a Unix lp daemon could perhaps run 4 and 6, and 
- talk 4 to the printer) and should thus not be discounted.  It depends on
- how limited the application space is (some student halls of residence have
- only http(s)/ssh/ftp/telnet outbound and nothing inbound, so could more
- easily be serviced by ALG/TRT type solutions).


6.4 M4: IPv6 Native LANs

   This ENPT exists when the ENAD wants to support the deployment of
   Native IPv6 LANs.  This condition will be driven by the EN transition
   variables V1-V14 stated in Section 4.

- IPv6 deployment in sites in 6NET has, where done extensively, been done by
- carrying IPv6 routing in parallel to the v4 routing, and then injecting the
- /64's from the v6-only hierarchy (admittedly FreeBSD-based at this stage)
- into the same VLANs as v4 subnets, overlaying v4 and v6 subnets, but of course
- with many more hosts available in the v6 space.   This can also carry IPv6
- only subnets in VLANs (e.g. for early trial deployments of IPv6 WLAN and of
- MIPv6 in that environment).   This is quite workable given the level of v6
- traffic until the enterprise vendors do smart L2/L3 v6 routing as they do
- for ipv4 now. 


6.5 M5: IPv6 Native Routing Domains

   This ENPT exists when the ENAD and/or the ENE wants to support the
   deployment of IPv6 Native Routing Domains.  This condition will be
   driven by the EN variables V1-14 stated in Section 4.

- as per 6.4, this can be done in parallel to v4 in an early (end host) dual
- stack deployment. 


6.6 M6: Dual Stack Nodes supporting IPv6 and IPv4

   This ENPT is a method to deploy IPv6 and a method for transition.  An
   EN that deploys DSNs as they adopt IPv6 are more assured that IPv6
   and IPv4 interoperation will be possible between the two nodes or
   services.  It also means for many legacy IPv4 nodes that they can be
   upgraded to support IPv4 and IPv6, but not turn on IPv6 until the
   IPv6 operational network has been verified to be interoperable and
   secure.  It also means that both IPv4 and IPv6 can be supported by
   the nodes that transition to IPv6 and then will be able to
   communicate with IPv4 nodes using an IPv4 network infrastructure.

- the big problem of course is then assumptions about which services are
- available via which IP versions (just look at the SMTP MX considerations
- draft for example).


6.7 M7: Single Stack IPv6 ONLY Nodes

   This ENPT will exist when ENs deploy IPv6 ONLY nodes.  At this time
   there are no known implementations of these node types.  This method
   for transition will require IPv6 NAT and the EN will lose IPv6
   capability and end-2-end security for IPv6 ONLY to IPv4 ONLY
   communications.

- Well, you can run Linux or FreeBSD IPv6-only, e.g. in an IPv6-only WLAN.  
- This has been done for a long time now in Tromso, Norway in a production
- academic network, and exists in smaller testbeds in other 6NET sites.

7. Enterprise Network Infrastructure Points of Transition

   The Enterprise will be required to determine what network
   infrastructure will be affected by transtion to IPv6. This
   infrastructure must be analyzed and understood as a critical resource
   to manage within the ENAD.  Each topic below in this section will be
   discussed and the issues facing transition for these network
   infrastructure parts will be discussed.

- A key requirement lies on the server side, e.g. being confident of interactions
- of NFS over IPv6 over a wide variety of client implementations.  This sort of
- support is still quite patchy (but some are robust).  

- I think a lot depends on whether you wish to keep existing v4 services v4
- only, and add new devices (like wlan) dual-stack, thus allowing access to
- legacy apps via v4 on DSNs and allowing innovation v6-v6 between the WLAN
- devices (the "clients" of the old world, now the new p2p endpoints).


7.1 DNS

This will be discussed in the next draft.

- e.g. whether to use the same or a separate name space for v and 6 in an
- early deployment.



7.5 Applications and APIs

This will be discussed in the next draft.

- There is now a v6 ops draft on porting, which should probably be referenced here


7.7 Network Management

This will be discussed in the next draft.

- I think now that's run over IPv4, querying IPv6 MIBs at the moment (e.g. the
- 6NET backbone is IPv6-only between the GSRs, but the access links between the
- backbone routers and the national PoPs has IPv4 to access the SNMP.

7.8 Address Planning

This will be discussed in the next draft.

- Should probably be a separate draft?  I'm not sure this is a design team
- transition issue per se.  It is worth noting though that a /48 isn't actually
- a lot of space for a large university, if certain types of new networks will
- exist (e.g. PANs).

SOme further quick comments:

I think here Itojun's draft on "missing IPv6 pieces" could be referenced for
items relevant to the enterprise (e.g. today you might point DNS at IPv4 root 
DNS servers).

The sections to be completed are quite broad in scope - are we taking on too
much, or must we really consider all these aspects fully at this stage?

There are also general requirements and properties of transition tools, e.g.
- how do they scale? (e.g. single NAT-PT restrictions)
- what are their security implications? (e.g. 6to4 relays)
- what are performance issues (packet overhead, encapsulation cpu)
- ipv4 and ipv6 address requirements (e.g. one static IPv4 for 6to4, ideally)
- application requirements (e.g. configuration of ALGs)
- ease of use/activation (for end users)
- ease of management (for admins)
- and probably many more...

cheers,

tim