www.archive-org-2013.com » ORG » 6 » 6NET

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

    Archived pages: 75 . Archive date: 2013-11.

  • Title: 6NET | Welcome to 6NET
    Descriptive info: .. What's New?.. |.. Contact.. Sections.. About 6NET.. Partners.. Publications.. Calendar.. Events.. Related Sites.. Private Area.. Welcome to 6NET.. 6NET was a three-and-a-half year European project to demonstrate that continued growth of the Internet can be met using new IPv6 technology.. The project built a native IPv6-based network connecting sixteen countries in order to gain experience of IPv6 deployment and migration from existing IPv4-based networks.. This was used to extensively test a variety of new IPv6 services and applications, as well as interoperability with legacy applications.. The 6NET project concluded on 30 June 2005, but IPv6 dissemination, training and support activities continue in the.. 6DISS project.. Latest News.. RFC 4242 published.. -.. 23 November 2005.. 6NET serves as catalyst for IPv6 deployments around the world.. 1 November 2005.. 6NET publishes 'An IPv6 Deployment Guide'.. 5 October 2005.. RFCs 3957, 4038 and 4057 published.. 23 May 2005.. Mobile IPv6 Handovers - Performance Analysis and Evaluation..  ...   Report on using multipoint applications over SSM.. 16 June 2005.. Final Report on IPv6 Deployment Issues.. IPv6 Basic Network Services Whitepaper published.. 8th edition of 6NET Newsletter published.. Hot Topics.. IPv6 Deployment Guide (6NET Book).. Latest Newsletter.. IPv6 Tiger Team.. IPv6 Eprints Archive.. Routing, DNS, intra-domain multicast, inter-domain multicast, and security cookbook.. IPv4 to IPv6 Migration Cookbook for ISPs and backbone networks.. IPv4 to IPv6 Transition Cookbook for end-sites.. IPv6 Renumbering in SOHO and Backbone Networks Cookbook.. IPv6 Renumbering in ISP and Enterprise Networks Cookbook.. Deploying IPv6 in School Networks Cookbook.. IPv6 Network Management Cookbook.. 6NET Informational Sheet.. IPv6: Facts and Fiction.. The 6NET Project is part-funded by the European Commission, but any opinions expressed on this server do not necessarily reflect the official opinion of the European Commission.. Please see '.. Information Society Technologies.. ' and '.. European Union Online.. ' for further information.. Contract No.. IST-2001-32603.. Copyright 6NET Consortium - Updated 05/02/2008..

    Original link path: /
    Open archive

  • Title: 6NET | What's New?
    Descriptive info: Home.. Added document -.. RFC 4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6).. Added press release -.. An IPv6 Deployment Guide.. D4.. 1.. 3: Mobile IPv6 Handovers: Performance Analysis and Evaluation, 2nd Version.. RFC 4057: IPv6 Enterprise Network Scenarios.. RFC 4038: Application Aspects of IPv6 Transition.. RFC 3964: Security Considerations for 6to4.. I-D: IPv6 Multicast Deployment Issues.. I-D: Route Advertisement Option for IPv6 Multicast Prefixes.. I-D: IPv6 multicast address assignment with DHCPv6.. I-D: All DRs all RPs model.. 2.. 2: Framework for the Support of IPv6 Wireless LANs, 2nd Version Bis.. 6.. 1: Description of IPv6 Network Mobility Demonstrators.. D7.. 10: Report on Creation of Tiger Team resource.. Added link -.. D3.. 2: Cookbook for IPv6 Renumbering in ISP and Enterprise Networks.. D5.. 14: Cookbook on deploying IPv6 in School Networks.. 15: Final report on applications development and evaluations (including descriptions of the demonstrators of WP5), and PoP deployment.. IPv6 and E-business Whitepaper.. 17 June 2005.. D2.. 3.. 4: Final IPv4 to IPv6 transition cookbook for end site networks/universities.. 10: Report on using multipoint applications over SSM.. 5.. 3: Final Report on IPv6 Deployment Issues (missing pieces for IPv6 deployment and IPv6-only operation).. IPv6 Basic Network Services Whitepaper.. 6NET Newsletter No.. 8.. 15 June 2005.. Greek Schools Network.. 14 June 2005.. 3: DHCPv6 implementation and test report, 3rd Version.. 1: Contribute and report on discussions on IPv6 support in RIPE database, 3rd Version.. 1: Cookbook for IPv6 Renumbering in SOHO and Backbone Networks.. 6 June 2005.. 6: Report on 3rd 6NET Workshop.. 25 May 2005.. Added workshop proceedings -.. 3rd 6NET Workshop.. RFC 4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6).. 3 May 2005.. 3: Evaluation report on the advantages demonstrated from use of IPv6 dynamic VPNs over different technologies.. 26 April 2005.. Added workshop information -.. 22 April 2005.. 4: Pre-Final IPv4 to IPv6 transition cookbook for end site networks/universities.. 7 April 2005.. 4.. 2: Report on IPv6 QoS Tests, 2nd Version.. 11 March 2005.. Updated page -.. 11 February 2005.. Added paper -.. Performance Evaluation of the Impact of Quality of Service mechanisms in an IPv6 network for IPv6.. 9 February 2005.. Added tutorial information -.. IPv6 Network Management Tutorial #3.. Observations of IPv6 Traffic on a 6to4 Relay.. 8 February 2005.. 4: Final MIPv6 Support Guide.. IPv6 Transitioning Management - Laying the Foundation for Managed IPv4/IPv6 Interoperation.. Added presentation -.. DHCPv6 und JOIN-SR.. Neuigkeiten rund um IPv6, 6Win und JOIN.. Renumbering Projekt.. 7 February 2005.. 4: Final IPv4 to IPv6 Transition Cookbook for Organisational/ISP (NREN) and Backbone Networks.. 3: Evaluation of Multihoming Solutions.. 11: Realisation of IPv6/IPv4 VoIP Integration Scenarios.. 13: Progress report on applications development and PoP deployment.. RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address.. I-D: IPv6 Network Architecture Protection.. I-D: v6tc Protocol Exploration.. I-D: NAT and Firewall Traversal for HIP.. I-D: IPv6 Transition/Co-existence Security Considerations.. I-D: Operational Considerations and Issues with IPv6 DNS.. I-D: Evaluation of IPv6 Auto-Transition Algorithm.. 28 January 2005.. IST 2004 Brochure.. IST 2004 Demonstrations Poster No.. e-Nations, The Internet for all.. 27 January 2005.. D1.. 6: Six-monthly report on the usage of 6NET.. 7.. Added page -.. Published Papers.. Presentations.. 20 January 2005.. 2: IPv6 cookbook for routing, DNS, intra-domain multicast, inter-domain multicast, and security, 2nd Version.. 1: Secure IPv6 Operation: Lessons learned from 6NET, 3rd Version.. 11 January 2005.. GFD.. 40: Guidelines for IP version independence in GGF specifications.. 41: Survey of IPv4 Dependencies in GGF specifications.. 9 January 2005.. 5: Multicast with mobile hosts: analysis and performance evaluation, 2nd Version.. 6 January 2005.. 9: Report on testing application over PIM-SSM deployment.. 10 December 2004.. Updated document -.. 2: Inter-domain Multicast.. 7 December 2004.. Updated meeting information -.. 6NET Consortium Meeting.. 22 November 2004.. 3: DHCPv6 implementation and test report, 2nd Version.. GRNET IPv6 Workshop.. 12 November 2004.. 1 November 2004.. IPv6 Over the Silk Satellite Network.. Source Specific Multicast (SSM) with IPv6.. IPv6 Campus Transition Experiences.. Evaluation of IPv6 Auto-Transition Algorithm.. I-D: Lifetime Option for DHCPv6.. 26 October 2004.. I-D: Things to think about when Renumbering an IPv6 network.. I-D: Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks.. I-D: Renumbering Requirements for Stateless DHCPv6.. I-D: IPv4 and IPv6 Dual-Stack Issues for DHCPv6.. I-D: IPv6 Campus Transition Scenario Description and Analysis.. 21 October 2004.. IPv6 Network Management Tutorial #2.. 20 October 2004.. 8 October 2004.. 2: Framework for the support of IPv6 Wireless LANs, 2nd Version.. 7 October 2004.. Added meeting information -.. 4 October 2004.. D6.. 3: Final report on IPv6 management and monitoring architecture design, tools, and operational procedures - Recommendations.. 24 September 2004.. 4: Final report on IPv6 management tools, developments and tests.. 18 September 2004.. 2: Dissemination and Use  ...   of IPv4 Dependencies in GGF specifications.. The 6NET Project: a narrow view.. IPv6 Multicast Deployment Experience.. Deployment, Tools and Applications of 6NET.. IPv6 Porting.. Introduction to IPv6 Porting.. IPv6, Grid Computing and Scaling-up the Internet.. IPv6 Globus Experiences.. Issues for the performance monitoring of an open source H.. 323 implementation.. GnomeMeeting.. From IPv4 to IPv6: The Case of OpenH323 Library.. 24 September 2003.. 2: Six-monthly usage on the usage of 6NET.. 2: Initial MIPv6 Support Guide.. 1: Specification of QoS Tests.. 11 September 2003.. 4 September 2003.. 2: Framework for the support of IPv6 Wireless LANs, 1st Version.. 1 September 2003.. 4: Report on 1st 6NET Open Workshop.. 8: Report on 2nd 6NET Training Workshop.. 20 August 2003.. 2nd 6NET Training Workshop.. 12 June 2003.. 6 August 2003.. 1: IPv6 Intra-domain Multicast Service.. 5 August 2003.. 3: Six-monthly report on usage of 6NET.. 2: Interim report on the implementation of tools and operational procedures.. 31 July 2003.. 2: Proxy DNS Installed.. The 6NET Project.. 30 July 2003.. 3: IPv6 multicast address allocation study.. 24 July 2003.. 3: Interim report on development and test.. 2: Dissemination and Use Plan, 3rd Version.. 22 July 2003.. 4: IPv4/IPv6 Multicast Interoperability.. 7 July 2003.. 6: Identification of Additional Users for All Activities.. 30 June 2003.. 9 June 2003.. 2 June 2003.. 1st 6NET Workshop.. 27 May 2003.. 1: First set of IPv6-enabled Dynamic VPNs running.. 20 May 2003.. 8 April 2003.. 5: Definition of generic framework for IPv6 applications trials and evaluation.. 28 March 2003.. 27 March 2003.. 24 March 2003.. 18 March 2003.. 11 March 2003.. 10 March 2003.. 2: Initial IPv4 to IPv6 Migration Cookbook for organizational/ISP (NREN) and backbone networks.. 5 March 2003.. 2: Operational procedures for secured management with transition mechanisms.. 2: Initial IPv4 to IPv6 transition cookbook for end-site networks/universities.. 3 March 2003.. Updated logo -.. Lancaster University.. 25 February 2003.. 11 February 2003.. 1 February 2003.. 29 January 2003.. 3: Initial applications development phase and PoP deployment progress report.. 4: Identification of user community for Activities 5.. 1 and 5.. 3: DHCPv6 implementation and test report, 1st Version.. 2: Management Architecture Specifications.. 21 January 2003.. 9 January 2003.. 2: Dissemination and Use Plan, 2nd Version.. 5 January 2003.. 1: Initial report on technology for wireless LAN/MAN transition to IPv6.. 1: Issues for IPv6 deployment (missing pieces for IPv6 deployment and IPv6-only operation).. 20 December 2002.. 17 December 2002.. 28 November 2002.. 27 November 2002.. GRNET.. 8 November 2002.. 5 November 2002.. 29 October 2002.. 1: Contribute and report on discussions on IPv6 support in RIPE database, 1st Version.. 28 October 2002.. 1: Report on IETF Multihoming Solutions, 1st Version.. 24 October 2002.. 1: 6NET IPv6 Network Management Cookbook.. Enabled IPv6 access.. 18 October 2002.. IPv6 Cluster.. Added logo -.. 17 October 2002.. Japanese IPv6 deployment status update.. 8 October 2002.. 4 October 2002.. Added diagram -.. 6NET Core Topology.. SWITCH.. 19 September 2002.. European Networking Activities.. 26 August 2002.. 23 August 2002.. 1: IPv4 to IPv6 migration scoping report for core networks.. 6 August 2002.. 5 August 2002.. 2: Dissemination and Use Plan, 1st Version.. 2 August 2002.. 1: Six-Monthly Report on the usage of 6NET.. 1: IPv4 to IPv6 migration scoping report for organisational (NREN) networks.. 1: IPv4 to IPv6 scoping report for end-site networks/universities.. 1: IPv6 Wireless LAN Access Issues.. 29 July 2002.. 24 July 2002.. 7: Report on 1st 6NET Training Workshop.. 9: Report on Liaison between 6NET and Euro6IX.. 22 July 2002.. 1st 6NET Training Workshop.. 19 July 2002.. 17 July 2002.. 16 July 2002.. 2: Identification of User Community for Activities 5.. 3 and 5.. 12 July 2002.. 1: 6NET Management Tools Requirements.. 1: 6NET Network Management Initial Architecture.. 6 July 2002.. 3: Report on Joint 6NET/Euro6IX Workshop.. 4 July 2002.. 1: Specification of IPv6 Applications to be developed within the project.. 3 July 2002.. 3: Operational procedures to be followed by organisations connected to 6NET.. 2 July 2002.. 24 June 2002.. 19 June 2002.. 12 June 2002.. Joint 6NET/Euro6IX Workshop.. 29 May 2002.. 27 May 2002.. PSNC Contribution to the 6NET Project.. 24 May 2002.. CESNET @ 6NET.. HUNGARNET in 6NET.. ETRI s role and contribution for 6NET.. 20 May 2002.. 17 May 2002.. Added document.. 1: Report on Project Website.. 3 May 2002.. 4: Procedures for the approval and scheduling of 6NET tests.. 1: IPv6 DNS service for the 6NET Network, 1st Version.. 1: Survey and evaluation of MIPv6 implementations.. 25 April 2002.. 22 April 2002.. 18 April 2002.. 11 April 2002.. 9 April 2002.. 1: IPv6 Routing Plan for the 6NET Network.. 8 April 2002.. 19 March 2002.. 7 March 2002.. 6 March 2002.. A Large-Scale International IPv6 Network.. 19 January 2002.. Website launched.. Copyright 6NET Consortium - Updated 23/11/2005..

    Original link path: /whatsnew.html
    Open archive

  • Title: 6NET | About 6NET
    Descriptive info: 6NET is a three-year European project to demonstrate that continued growth of the Internet can be met using new IPv6 technology.. It also aims to help European research and industry play a leading role in defining and developing the next generation of networking technologies.. 6NET involves thirty-five partners from the commercial, research and academic sectors and represents a total investment of EUR 18 million; EUR 7 million of which will come from the project partners themselves, and EUR 11 million from the Information Society Technologies Programme of the European Commission.. The project started on 1 January 2002 and runs until 31 December 2004.. Objectives.. Install and operate an international pilot IPv6 network with both static and mobile components in order to gain a better understanding of IPv6 deployment issues.. This network will primarily use native IPv6 links (initially running at 155 Mbps and increasing to 2.. 5 Gbps in the second year), although encapsulation over IPv4 infrastructure may be necessary in some cases.. Test the migration strategies for integrating IPv6 networks with existing IPv4 infrastructure.. Introduce and test new IPv6 services and applications, as well as legacy services and applications on IPv6 infrastructure.. Evaluate address allocation, routing and DNS operation for IPv6 networks.. Collaborate with other IPv6 activities and standardisation bodies.. Promote IPv6 technology.. Work Packages..  ...   Southampton.. WP3: Basic Network Services.. This work package will design, implement and test IPv6-enabled network services such as routing (both inter-domain and intra-domain), DNS, DHCP, registry procedures, quality-of-service (QoS) and multicasting.. It will also focus on interoperability between IPv6 and IPv4 network services.. Lead Partner: ACONET.. WP4: Application and Service Support.. This work package will identify and implement applications and services that support network mobility.. These include autoconfiguration, handoff, multihoming, renumbering, virtual private networks (VPNs) and quality-of-service (QoS).. Lead Partner: University of Lancaster.. WP5: IPv6 Middleware and User Application Trials.. This work package will trial IPv6-enabled middleware and user applications.. These include real-time videoconference and media streaming applications, online gaming, relational databases, transaction processing systems, and portal services.. Lead Partner: IBM.. WP6: Network Management Architecture and Tools.. This work package will consider configuration, performance, fault, security and availability management issues.. It will also develop and test appropriate management tools.. Lead Partner: RENATER.. WP7: Dissemination and Exploitation of Results.. This work package will maintain the 6NET web server, organise workshops, present papers at conferences and other events, liaise with standardisation bodies, and develop business models.. It will also provide training to the project partners.. Lead Partner: TERENA.. Copyright 6NET Consortium - Updated 08/11/2004.. This page has been translated to Serbo-Croatian by Vera Djuraskovic available at.. Webhostinggeeks.. com..

    Original link path: /overview.html
    Open archive

  • Title: 6NET | Partners
    Descriptive info: Cisco Systems International BV.. Haarlerbergpark.. Haarlerbergweg 13-19.. 1101 CH Amsterdam.. The Netherlands.. Coordinator.. Czech National Research and Education Network (CESNET).. Zikova 4.. 160 00 Prague.. Czech Republic.. Principal Contractor.. Delivery of Advanced Network Technology to Europe Ltd.. (DANTE).. Francis House.. 112 Hills Road.. Cambridge CB2 1PQ.. United Kingdom.. Deutsche Forschungsnetz Verein (DFN).. Anhalterstraße 1.. 10963 Berlin.. Germany.. Electronics and Telecommunications Research Institute (ETRI).. 161 Kajong-Dong.. Yusong-Gu.. 305-350 Taejon.. Korean Republic.. Fundação para a Computação Científica Nacional (FCCN).. Av.. do Brasil 101.. 1700-066 Lisbon.. Portugal.. Greek Research Technology Network (GRNET).. 56 Mesogion Av.. 115 27 Athens.. Greece.. Hungarian Academic and Research Network Association (HUNGARNET).. Victor Hugo U.. 18-22.. 1132 Budapest.. Hungary.. Compagnie IBM France.. Avenue Gambetta 2.. 92400 Courbevoie.. France.. Consortium GARR.. Via Palmiro Togliatti 1625.. 00155 Rome.. Italy.. NORDUnet A/S.. Bøge Alle 5.. 2970 Hørsholm.. Denmark.. NTT Communications Corporation.. 1-1-6 Uchisaiwai-cho.. Chiyoda-ku.. 100-8019 Tokyo Japan.. Poznan Supercomputing and Networking Centre (PSNC).. Noskowskiego 10.. 61-704 Poznañ.. Poland.. Réseau National de Telecommunication pour la Technologie, l Enseignement et al Recherche (RENATER)..  ...   Amsterdam.. United Kingdom Education Research Networking Association (UKERNA).. Atlas Centre.. Chilton.. Didcot OX11 0QS.. Université Libre de Bruxelles (ULB).. Avenue Franklin Roosevelt 50.. 1050 Brussels.. Belgium.. University College London (UCL).. Gower Street.. London WC1E 6BT.. Bailrigg.. Lancaster LA1 4YW.. University of Southampton.. Highfield.. Southampton SO17 1BJ.. University of Vienna Computer Centre (ACOnet).. Dr Karl Lueger Ring 1.. 1010 Vienna.. Austria.. Computer Technology Institute (CTI).. 61 Riga Feraiou Street.. 26221 Patras.. Assistant Contractor.. Danmarks Tekniske Universitet (DTU).. Anker Engelundsvej 1.. Bygning 101A.. 2800 Kgs.. Lyngby.. Fraunhofer Institute FOKUS (FhG).. Kaiserin-Augusta-Allee 31.. 10589 Berlin.. Institut National de Recherche en Informatique et en Automatique (INRIA).. Domaine de Voluceau.. Rocquencourt - B.. P.. 105.. 78153 Le Chesnay Cedex.. Invenia A/S.. Forskningsparken.. 9291 Tromsø.. Norway.. Oulu Polytechnic.. Albertinkuja 20.. 90100 Oulu.. Finland.. Scientific Computing Ltd.. (CSC).. Tekniikantie 15 a D.. 02101 Espoo.. UNINETT A/S.. Tempeveien 22/4.. 7037 Trondheim.. Université Louis Pasteur (ULP).. 4 rue Blaise Pascal.. 67070 Strasbourg Cedex.. University of Oulu.. Pentti Kaiteran katu 1.. 90014 Oulu.. Westfälische Wilhelms-Universität (WWU-JOIN).. Schloßplatz 2.. 48149 Münster..

    Original link path: /partners.html
    Open archive

  • Title: 6NET | Publications
    Descriptive info: Books.. 6NET IPv6 Deployment Guide.. October 2005.. Press Releases.. 20 November 2003.. Europe to build the world s highest capacity IPv6 Research Network.. 4 December 2001.. Newsletters.. June 2002.. December 2002.. June 2003.. January 2004.. May 2004.. September 2004.. January 2005.. June 2005.. Informational.. November 2004.. September 2002.. June 2004.. Public Deliverables.. WP2: IPv4-IPv6 Coexistence, Networking and Migration.. Request for Comments (RFCs).. Internet Drafts (I-Ds).. GGF Specifications.. Other.. Copyright 6NET Consortium - Updated 01/11/2005..

    Original link path: /publications/index.html
    Open archive

  • Title: 6NET | Calendar
    Descriptive info: Date.. Event.. Venue.. 2005.. 27 January.. South Asian IPv6 Summit.. Bangalore, India.. 24-28 January.. 19th APAN Meeting.. Bangkok, Thailand.. 26-28 January.. Prague, Czech Republic.. 23 February.. 3rd Asia-Pacific IPv6 Summit.. Kyoto, Japan.. 9 February.. 6NET Technical Audit Preparation Meeting.. Diegem, Belgium.. 10-11 February.. 6NET Technical Audit.. 13-16 February.. ESCC/Internet2 Joint Techs Workshops.. Salt Lake City, USA.. 2-3 March.. IPv6 Network Management Tutorial.. Belgrade, Serbia & Montenegro.. 6-11 March.. IETF 62.. Minneapolis, USA.. 14-17 March.. Global Grid Forum 13.. Seoul, South Korea.. 17-18 March.. 2nd EC-Bridge Conference.. Beijing, China.. 5-8 April.. NORDUnet 2005.. Longyearbyen, Svalbard.. 4-6 April.. Global IPv6 Summit  ...   May.. 6NET Final Event / 3rd 6NET Workshop.. Pisa, Italy.. 6-9 June.. TERENA Networking Conference 2005.. Poznan, Poland.. 20-24 June.. EUNIS 2005.. Manchester, United Kingdom.. 22 June.. Lisbon, Portugal.. 23-24 June.. 26-29 June.. Global Grid Forum 14.. Chicago, USA.. 28-29 July.. 18th TF-NGN Meeting.. Paris, France.. 31 July - 5 August.. IETF 63.. 23-27 August.. 20th APAN Meeting.. Taipei, Taiwan.. 19 September.. North American IPv6 Summit.. San Jose, USA.. 19-22 September.. Philadelphia, USA.. 9-12 October.. Global Grid Forum 15.. Boston, USA.. 10-14 October.. RIPE 51.. Amsterdam, The Netherlands.. 6-11 November.. IETF 64.. TBD, Canada.. Copyright 6NET Consortium - Updated 11/03/2005..

    Original link path: /calendar.html
    Open archive

  • Title: 6NET | Events
    Descriptive info: General.. 5 June 2002, Limerick, Ireland.. 21 May 2003, Zagreb, Croatia.. 9 June 2004, Rhodes, Greece.. 11-12 May 2005, Pisa, Italy.. Training.. 14-15 May 2002, Diegem, Belgium.. 3-4 March 2003, Diegem, Belgium.. 4-6 October 2004, Montpellier, France.. 24-26 November 2004, Budapest, Hungary.. 2-3 March 2005, Belgrade, Serbia & Montenegro.. 19 October 2004, Athens, Greece.. Copyright 6NET Consortium - Updated 25/05/2005..

    Original link path: /events/index.html
    Open archive

  • Title: 6NET | Related sites
    Descriptive info: Related sites.. 6NET Local Sites.. 6NET Applications Database.. 6NET FOKUS.. 6NET Greece.. 6NET Italia.. Hungarian 6NET Project.. JOIN IPv6-Referenzzentrum.. (German).. PSNC IPv6 Network.. UK IPv6 Resource Centre.. European Commission.. Information Society Technologies (IST).. Research Networking in FP5.. IST Projects.. 6LINK.. 6WINIT.. Euro6IX.. GCAP.. GÉANT.. LONG.. MIND.. Moby Dick.. NGNi.. NGN-LAB.. Tsunami.. IPv6 Activities.. 6Bone.. IPv6 Research Education Networks (6REN)..  ...   IPv6 Working Group.. Internet2 IPv6 Working Group.. RIPE IPv6 Working Group.. TERENA/DANTE TF-NGN.. 6WiN.. Standardisation Bodies.. European Telecommunication Standards Institute (ETSI).. International Telecommunications Union (ITU).. Internet Engineering Task Force (IETF).. Internet Research Task Force (IRTF).. Global Grid Forum (GGF).. Other useful links.. Provisional IPv6 Assignment and Allocation Policy.. How-to IPv6 in Globus Toolkit 3.. Copyright 6NET Consortium - Updated 21/06/2005..

    Original link path: /related.html
    Open archive

  • Title:
    Descriptive info: Network Working Group S.. Venaas Request for Comments: 4242 UNINETT Category: Standards Track T.. Chown University of Southampton B.. Volz Cisco Systems, Inc.. November 2005 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol.. Distribution of this memo is unlimited.. Copyright Notice Copyright (C) The Internet Society (2005).. Abstract This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6.. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.. Table of Contents 1.. Introduction.. 2 2.. Terminology.. 2 3.. Information Refresh Time Option Definition.. Constants.. 3 3.. Client Behaviour.. Server Behaviour.. 4 3.. Option Format.. 5 4.. IANA Considerations.. 5 5.. Acknowledgements.. 5 6.. Security Considerations.. 5 7.. References.. 6 7.. Normative References.. Informative References.. 6 Venaas, et al.. Standards Track [Page 1] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 1.. Introduction DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts.. However, many hosts will use stateless autoconfiguration as specified in [RFC2462] for address assignment, and use DHCPv6 only for other configuration data; see [RFC3736].. This other configuration data will typically have no associated lifetime, hence there may be no information telling a host when to refresh its DHCPv6 configuration data.. Therefore, an option that can be used from server to client to inform the client when it should refresh the other configuration data is needed.. This option is useful in many situations: - Unstable environments where unexpected changes are likely to occur.. - For planned changes, including renumbering.. An administrator can gradually decrease the time as the event nears.. - Limit the amount of time before new services or servers are available to the client, such as the addition of a new NTP server or a change of address of a DNS server.. See [RFC4076].. 2.. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].. 3.. Information Refresh Time Option Definition The information refresh time option specifies an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6.. It is only used in Reply messages in response to Information-Request messages.. In other messages there will usually be other options that indicate when the client should contact the server, e.. g.. , addresses with lifetimes.. Note that it is only an upper bound.. If the client has any reason to make a DHCPv6 request before the refresh time expires, it should attempt to refresh all the data.. A client may contact the server before the refresh time expires.. Reasons it may do this include the need for additional configuration Venaas, et al.. Standards Track [Page 2] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 parameters (such as by an application), a new IPv6 prefix announced by a router, or that it has an indication that it may have moved to a new link.. The refresh time option specifies a common refresh time for all the data.. It doesn't make sense to have different refresh time values for different data, since when the client has reason to refresh some of its data, it should also refresh the remaining data.. Because of this, the option must only appear in the options area of the Reply message.. The expiry of the refresh time in itself does not in any way mean that the client should remove the data.. The client should keep its current data while attempting to refresh it.. However, the client is free to fall back to mechanisms other than DHCPv6 if it cannot refresh the data within a reasonable amount of time.. When a client receives a Reply to an Information-Request that contains configuration information, it should install that new configuration information after removing any previously received configuration information.. It should also remove information that is missing from the new information set, e.. , an option might be left out or contain only a subset of what it did previously.. Constants We define two constants for use by the protocol.. How they are used is specified in the sections below.. IRT_DEFAULT 86400 In some cases the  ...   MUST NOT be smaller than IRT_MINIMUM.. The server SHOULD give a warning if it is configured with a smaller value.. The option MUST only appear in the options area of Reply messages.. Standards Track [Page 4] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 3.. Option Format The format of the information refresh time option is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | information-refresh-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_INFORMATION_REFRESH_TIME (32) option-len 4 information-refresh-time Time duration relative to the current time, expressed in units of seconds 4.. IANA Considerations The IANA has assigned an option code for the information refresh time option from the DHCPv6 option-code space [RFC3315].. 5.. Acknowledgements The authors thank Mat Ford, Tatuya Jinmei, Ted Lemon, Thomas Narten, Joe Quanaim, and A.. K.. Vijayabhaskar for valuable discussions and comments.. 6.. Security Considerations Section 23 of [RFC3315] outlines the DHCPv6 security considerations.. This option does not change these in any significant way.. An attacker could send faked Reply messages with a low information refresh time value, which would trigger use of IRT_MINIMUM to minimize this threat.. Another attack might be to send a very large value, to make the client use forged information for a long period of time.. A possible maximum limit at the client is suggested, which would reduce this problem.. Standards Track [Page 5] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 7.. References 7.. Normative References [RFC2119] Bradner, S.. , "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.. [RFC2462] Thomson, S.. and T.. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.. [RFC3315] Droms, R.. , Bound, J.. , Volz, B.. , Lemon, T.. , Perkins, C.. , and M.. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.. [RFC3736] Droms, R.. , "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.. 7.. Informative References [RFC4076] Chown, T.. , Venaas, S.. , and A.. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.. Standards Track [Page 6] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 Authors' Addresses Stig Venaas UNINETT Trondheim NO 7465 Norway EMail: venaas@uninett.. no Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.. soton.. ac.. uk Bernard Volz Cisco Systems, Inc.. 1414 Massachusetts Ave.. Boxborough, MA 01719 USA EMail: volz@cisco.. com Venaas, et al.. Standards Track [Page 7] RFC 4242 Information Refresh Time Option for DHCPv6 November 2005 Full Copyright Statement Copyright (C) The Internet Society (2005).. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights.. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.. ietf.. org/ipr.. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard.. Please address the information to the IETF at ietf- ipr@ietf.. org.. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.. Standards Track [Page 8]..

    Original link path: /publications/standards/rfc4242.txt
    Open archive

  • Title: 6NET | Publications | Standards Contributions
    Descriptive info: This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6.. Published: November 2005.. This document describes the scenarios for IPv6 deployment within enterprise networks.. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios.. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment.. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment.. The results of that analysis will be published in a separate document.. Published: June 2005.. IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically.. However, further settings are not available.. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used.. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks.. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.. , the addition of a new NTP server address, a change in DNS search paths, or full site renumbering.. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.. Published: May 2005.. As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications.. This document specifies scenarios and aspects of application transition.. It also proposes guidelines on how to develop IP version-independent applications during the transition period.. Published: March 2005.. The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks.. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet.. This characteristic enables a number of security threats, mainly Denial of Service.. It also makes it easier for nodes to spoof IPv6 addresses.. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.. Published: December 2004.. This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address.. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism.. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well.. This memo updates the addressing format presented in RFC 3306.. Published: November 2004.. In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers.. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented.. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.. Published: September 2003.. (Expired).. This memo describes known issues with IPv6 multicast, and provides historical reference of how some earlier problems have been resolved.. Published: February 2005 Version: 2.. This document defines a way to advertise IPv6 multicast prefix availability using Neighbor Discovery (RFC2461).. This multicast RA option can be used by routers to announce a set of multicast prefixes that can be on the link to form new group addresses.. Published: February 2005 Version: 0.. This document proposes a simple solution to solve IPv6 multicast address assignment problem using the DHCPv6 protocol.. Published: February 2005 Version: 1.. This document defines a new model for IPv6 ASM (Any Source Multicast) where the Designated Router (DR) on each LAN can serve as a Rendezvous Point (RP) for group addresses formed from the RP address.. This keeps group-to-RP mapping simple, while providing for multicast address allocation coordination to be kept within a subnet.. Published: January 2005 Version: 0.. Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6.. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site.. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT.. Published: January 2005 Version: 1.. This document aims to provide a rough sketch on different approaches to meet the zeroconf/assisted tunneling requirements for a simple IPv6-in-IPv4 tunnel set-up mechanism.. Published: December 2004 Version: 0.. The Host Identity Protocol is a signaling protocol which adds another layer to the Internet model and establishes IPsec ESP SAs to protect subsequent data traffic.. HIP also aims to interwork with middleboxes (such as NATs and Firewalls).. This document investigates this aspect in more detail.. Published: October 2004 Version: 3.. The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms.. This document attempts to give an overview of the various issues grouped into three categories: Issues due to the IPv6 protocol itself, due to transition mechanisms, and due to the way in which IPv6 is being deployed.. This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehaviour, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues.. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.. Published: October 2004 Version: 10.. This memo evaluates a method called "auto-transition" to ensure that any device can obtain IPv6 connectivity at any time and whatever network is attached to, even if such network is connected to  ...   forwarding labeled packets, and the requirements for flow state establishment methods.. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.. Published: April 2003 Version: 7.. ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices cause a significant increase the routing table size, change rates and instability, the tragedy of the commons by encouraging selfish routing practices, the exhaustion of the 16-bit AS number space, and may collapse the Internet interdomain routing architecture.. As there has been a desire to avoid similar problems as seen with IPv4, the use of similar techniques to achieve site multihoming has been prevented operationally in IPv6.. However, the long effort to proceed with other IPv6 multihoming mechanisms has produced lots of heat but little light.. This memo tries to list available techniques, split the organizations to different types to separately examine their multihoming needs, to look at the immediate and short-term solutions for these organization types, and to list a few immediate action items on how to proceed with IPv6 site multihoming.. Published: April 2003 Version: 0.. There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment.. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end-to-end encrypted traffic and peer-to-peer applications.. There may also be need to extend packet matching to include some Extension Header or Destination Option fields.. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds.. Published: March 2003 Version: 1.. The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is a subject of much debate.. However, the big picture of the transition seems not to have been discussed sufficiently.. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process.. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches.. Published: February 2003 Version: 0.. This document describes an IPv4 - IPv6 gateway solution that embeds all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts to receive from and send to IPv4 multicast groups.. In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes.. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6.. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS-number space.. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4.. Published: January 2003 Version: 0.. The purpose of the privacy extensions for stateless address autoconfiguration [1] is to change the interface identifier (and the global-scope addresses generated from it) over time in order to make it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.. Current Distributed Denial of Service (DDoS) [2] attacks employ forged source addresses which can also be in the same prefixes than the real addresses of the compromised nodes used for attacks.. Indeed, network ingress filtering defeats DDoS using "random" forged source addresses.. The issue developed in this document is that the behavior of a compromised node used as source in a DDoS attack with "in-prefix" spoofed source address and the behavior of nodes using temporary addresses at high rate can not be distinguished.. This could make future defenses against DDoS attacks very hard.. Published: January 2003 Version: 2.. All IPv6 nodes must be able to process Routing Header [IPV6] and Home Address [MIPV6] Options.. With these, packet filter access lists can be tricked (among other things) as the destination and source addresses, respectively, are being rewritten as the packet traverses the network.. Some of the security considerations of these features are analyzed, and a few possible solutions presented.. It will be shown that with the current architecture, the network-based security does not seem to scale to the requirements of Mobile IPv6; it seems possible that unless security is taken seriously when implementing the nodes, the new Mobile IPv6 requirements might not be allowed to be used at all in some circumstances.. Published: December 2002 Version: 3.. Currently, IPv6 Internet is, globally considered, inseparable from the 6bone network.. The 6bone has been built as a tighly meshed tunneled topology.. As the number of participants has grown, it has become an untangible mess, hindering the real deployment of IPv6 due to low quality of connections.. This memo discusses the nature and the state of 6bone/IPv6 Internet, points out problems and outlines a few ways to start fixing them; also, some rough operational guidelines for different-sized organizations are presented.. The most important issues are: not offering transit to everyone and real transit operators being needed to take a more active role.. Published: November 2002 Version: 1.. There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast.. This memo describes known problems, trying to raise awareness.. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs.. Site-scoped multicast is also problematic when used alongside to global multicast because of that.. A few possible solutions are outlined or referred to.. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up.. Finally, a feature request for MLD snooping switches is noted.. This document serves two functions.. Its motivation is to aid in the creation of IP-version independent specifications and consequently, in the transition of IPv4 to IPv6.. First, it describes how to avoid IPv4 dependencies in GGF specifications.. Secondly, it outlines new, IPv6-specific issues for application designers and implementers.. It should be used by all GGF WGs and as a checklist for document approval.. Published: 7 January 2005.. This document is a survey of IPv4 dependencies on current Global Grid Forum (GGF) specifications.. It is an informational document, intended to be used as a checklist for planning future specification revisions.. Published: 26 November 2004.. Copyright 6NET Consortium - Updated 24/11/2005..

    Original link path: /publications/standards/index.html
    Open archive

  • Title:
    Descriptive info: Network Working Group J.. Bound, Ed.. Request for Comments: 4057 Hewlett Packard Category: Informational June 2005 IPv6 Enterprise Network Scenarios Status of This Memo This memo provides information for the Internet community.. It does not specify an Internet standard of any kind.. Abstract This document describes the scenarios for IPv6 deployment within enterprise networks.. Introduction.. 2 2.. Terminology.. 3 3.. Base Scenarios.. 4 3.. Base Scenarios Defined.. Scenarios Network Infrastructure Components.. 5 3.. Specific Scenario Examples.. 8 3.. Applicability Statement.. 10 4.. Network Infrastructure Component Requirements.. DNS.. 11 4.. Routing.. Configuration of Hosts.. Security.. Applications.. 12 4.. Network Management.. Address Planning.. 12 Bound Informational [Page 1] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 4.. Multicast.. 9.. Multihoming.. 12 5.. Security Considerations.. 12 6.. Normative References.. 13 Acknowledgements.. 13 1.. Introduction This document describes the scenarios for IPv6 deployment within enterprise networks.. 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.. It is expected those teams include members from management, network operations, and engineering.. The scenarios presented provide an example set of cases the enterprise can use to build an IPv6 network scenario.. To frame the discussion, this document will describe a set of scenarios each with a network infrastructure.. It is impossible to define every possible enterprise scenario that will apply to IPv6 adoption and transition.. 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, simply will not work.. This document does not try to depict the drivers for adoption of IPv6 by an enterprise.. While it is difficult to quantify all the scenarios for an enterprise network team to plan for IPv6, it is possible to depict a set of abstract scenarios that will assist with planning.. This document presents three base scenarios to be used as models by enterprises defining specific scenarios.. The first scenario assumes the enterprise decides to deploy IPv6 in conjunction with IPv4.. The second scenario assumes the enterprise decides to deploy IPv6 because of a specific set of applications that Bound Informational [Page 2] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 it wants to use over an IPv6 network.. The third scenario assumes an enterprise is building a new network or restructuring an existing network and decides to deploy IPv6 as the predominant protocol within the enterprise coexisting with IPv4.. This document then briefly reviews a set of network infrastructure components that must be analyzed, which are common to most enterprises.. This document then provides three specific scenario examples using the network infrastructure components to depict the requirements.. These are common enterprise deployment cases to depict the challenges for the enterprise to transition a network to IPv6.. Next, supporting legacy functions on the network (while the transition is in process), and the network infrastructure components requiring analysis by the enterprise are discussed.. 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 will depict functions in their networks that require consideration for IPv6 deployment and transition.. Using the scenarios, network infrastructure components, and examples in this document, an enterprise can define its specific scenario requirements.. Understanding the legacy functions and network infrastructure components required, the enterprise can determine the network operations required to deploy IPv6.. The tools and mechanisms to support IPv6 deployment operations will require enterprise analysis.. The analysis to determine the tools and mechanisms to support the scenarios will be presented in subsequent document(s).. Terminology Enterprise Network - A network that has multiple internal links, one or more router connections to one or more Providers, and is actively managed by a network operations entity.. Provider - An entity that provides services and connectivity to the Internet or other private external networks for the enterprise network.. IPv6 Capable - A node or network capable of supporting both IPv6 and IPv4.. IPv4 only - A node or network capable of supporting only IPv4.. Bound Informational [Page 3] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 IPv6 only - A node or network capable of supporting only IPv6.. This does not imply an IPv6 only stack in this document.. Base Scenarios 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.. Below we use the term network infrastructure to mean the software, network operations and configuration, and methods used to operate a network in an enterprise.. For the base scenarios it is assumed that any IPv6 node is IPv6 capable.. Base Scenarios Defined Scenario 1: Wide-scale/total dual-stack deployment of IPv4 and IPv6 capable hosts and network infrastructure.. Enterprise with an existing IPv4 network wants to deploy IPv6 in conjunction with their IPv4 network.. Assumptions: The IPv4 network infrastructure used has an equivalent capability in IPv6.. Requirements: Do not disrupt existing IPv4 network infrastructure assumptions with IPv6.. IPv6 should be equivalent or "better" than the network infrastructure in IPv4.. However, it is understood that IPv6 is not required to solve current network infrastructure problems, not solved by IPv4.. It may also not be feasible to deploy IPv6 on all parts of the network immediately.. Scenario 2: Sparse IPv6 dual-stack deployment in IPv4 network infrastructure.. Enterprise with an existing IPv4 network wants to deploy a set of particular IPv6 "applications" (application is voluntarily loosely defined here, e.. , 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, and platforms for the application are IPv6 capable.. Bound Informational [Page 4] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 Requirements: Do not disrupt IPv4 infrastructure.. Scenario 3: IPv6-only network infrastructure with some IPv4-capable nodes/applications needing to communicate over the IPv6 infrastructure.. Enterprise deploying a new network or restructuring an existing network, decides IPv6 is the basis for most network communication.. Some IPv4 capable nodes/applications will need to communicate over that infrastructure.. Assumptions: Required IPv6 network infrastructure is available, or available over some defined timeline, supporting the enterprise plan.. Requirements: Interoperation and Coexistence with IPv4 network infrastructure and applications are required for communications.. Scenarios Network Infrastructure Components This section defines the network infrastructure that exists for the above enterprise scenarios.. This is not an exhaustive list, but a base list that can be expanded by the enterprise for specific deployment scenarios.. The network infrastructure components are presented as functions that the enterprise must analyze as part of defining their specific scenario.. The analysis of these functions will identify actions that are required to deploy IPv6.. Network Infrastructure Component 1 Enterprise Provider Requirements - Is external connectivity required? - One site vs.. multiple sites and are they within different geographies? - Leased lines or VPNs? - If multiple sites, how is the traffic exchanged securely? - How many global IPv4 addresses are available to the enterprise? - What is the IPv6 address assignment plan available from the provider? - What prefix delegation is required by the Enterprise? - Will the enterprise be multihomed? - What multihoming techniques are available from the provider? - Will clients within the enterprise be multihomed? - Does the provider offer any IPv6 services? - Which site-external IPv6 routing protocols are required? - Is there an external data center to the enterprise, such as servers located at the Provider? - Is IPv6 available using the same access links as IPv4, or different ones? Bound Informational [Page 5] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 Network Infrastructure Component 2 Enterprise Application Requirements - List of applications in use? - Which applications must be moved to support IPv6  ...   can never be used.. - Nodes must be able to access IPv4 legacy applications over IPv6 network.. Applicability Statement The specific network scenarios selected are chosen to depict a base set of examples, and to support further analysis of enterprise networks.. This is not a complete set of network scenarios.. Though Example Network C is a verifiable use case, currently the scenario defines an early adopter of enterprise networks transitioning to IPv6 as a predominant protocol strategy (i.. , IPv6 Routing, Applications, Security, and Operations), viewing IPv4 as legacy operations immediately in the transition strategy, and at this time may not be representative of many initial enterprise IPv6 deployments.. Each enterprise planning team will need to make that determination as IPv6 deployment evolves.. 4.. Network Infrastructure Component Requirements The enterprise will need to determine which network infrastructure components require enhancements or need to be added for deployment of IPv6.. This infrastructure will need to be analyzed and understood as a critical resource to manage.. The list in this section is not exhaustive, but contains the essential network infrastructure components for the enterprise to consider before beginning to define more fine-tuned requirements such as QOS, PKI, or Bandwidth requirements for IPv6.. The components are only identified here and their details will be discussed in the analysis document for enterprise scenarios.. References currently available for components are provided.. Bound Informational [Page 10] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 4.. 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.. The range of DNS operational issues is beyond the scope of this document.. However, DNS resolution and transport solutions for both IP protocols are influenced by the chosen IPv6 deployment scenario.. Users need to consider all current DNS IPv4 operations and determine if those operations are supported for IPv6 [DNSV6].. Routing Interior and Exterior routing will be required to support both IPv4 and IPv6 routing protocols, and the coexistence of IPv4 and IPv6 over the enterprise network.. The enterprise will need to define the IPv6 routing topology, any ingress and egress points to provider networks, and transition mechanisms that they wish to use for IPv6 adoption.. The enterprise will also need to determine what IPv6 transition mechanisms are supported by their upstream providers.. Configuration of Hosts IPv6 introduces the concept of stateless autoconfiguration in addition to stateful autoconfiguration, for the configuration of hosts within the enterprise.. The enterprise will have to determine the best method of host configuration for its network, if it will use stateless or stateful autoconfiguration, and how autoconfiguration will operate for DNS updates.. It will also need to determine how prefix delegation will be done from their upstream provider and how those prefixes will be cascaded down to the enterprise IPv6 network.. The policy for DNS or choice of autoconfiguration is out of scope for this document [CONF, DHCPF, DHCPL].. 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.. The entire security infrastructure currently used in the enterprise needs to be analyzed against IPv6 deployment effect to determine what is supported in IPv6.. Users should review other current security IPv6 network infrastructure work in the IETF and within the industry.. Users will have to work with their platform and software providers to determine which IPv6 security network infrastructure components are supported.. The security filters and firewall requirements for IPv6 need to be determined by the enterprise.. The policy choice of users for security is beyond the scope of this document.. Bound Informational [Page 11] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 4.. Applications Existing applications will need to be ported or provide proxies to support both IPv4 and IPv6 [APPS].. Network Management The addition of IPv6 network infrastructure components will need to be managed by the enterprise network operations center.. Users will need to work with their network management platform providers to determine what is supported for IPv6 while planning IPv6 adoption, and which tools are available to monitor the network.. Network management will not need to support both IPv4 and IPv6 and view nodes as dual stacks.. Address Planning The address space within the enterprise will need to be defined and coordinated with the routing topology of the enterprise network.. It is also important to identify the pool of IPv4 address space available to the enterprise to assist with IPv6 transition methods.. Multicast Enterprises utilizing IPv4 Multicast services will need to consider how these services may be implemented operationally in an IPv6- enabled environment.. Multihoming At this time, current IPv6 allocation policies are mandating the allocation of IPv6 address space from the upstream provider.. If an enterprise is multihomed, the enterprise will have to determine how it wishes to support multihoming.. This also is an area of study within the IETF and work in progress.. Security Considerations This document lists scenarios for the deployment of IPv6 in enterprise networks, and there are no security considerations associated with making such a list.. There will be security considerations for the deployment of IPv6 in each of these scenarios, but they will be addressed in the document that includes the analysis of each scenario.. Bound Informational [Page 12] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 6.. Normative References [DNSV6] Durand, A.. , Ihren, J.. , and P.. Savola, "Operational Considerations and Issues with IPv6 DNS", Work in Progress.. [CONF] Thomson, S.. [DHCPF] Droms, R.. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003 [DHCPL] Nikander, P.. , Kempf, J.. , and E.. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.. [APPS] Shin, M-K.. , Hong, Y-G.. , Hagino, J.. , Savola, P.. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.. Acknowledgements The Authors would like to acknowledge contributions from the following: IETF v6ops Working Group, Alan Beard, Brian Carpenter, Alain Durand, Bob Hinden, and Pekka Savola.. Bound Informational [Page 13] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 Authors' Addresses Yanick Pouffary (Chair of Design Team) HP Competency Center 950, Route des Colles, BP027, 06901 Sophia Antipolis CEDEX FRANCE Phone: + 33492956285 EMail: Yanick.. pouffary@hp.. com Jim Bound (Editor) Hewlett Packard 110 Spitbrook Road Nashua, NH 03062 USA Phone: (603) 884-0062 EMail: jim.. bound@hp.. com Marc Blanchet Viagenie inc.. 2875 boul.. Laurier, bur.. 300 Ste-Foy, Quebec, G1V 2M2 Canada EMail: Marc.. Blanchet@viagenie.. qc.. ca Tony Hain Cisco Systems 500 108th Ave.. N.. E.. Suite 400 Bellevue, WA 98004 USA EMail: alh-ietf@tndh.. net Paul Gilbert Cisco Systems 1 Penn Plaza, 5th floor, NY, NY 10119 USA Phone: (212) 714-4334 EMail: pgilbert@cisco.. com Bound Informational [Page 14] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 Margaret Wasserman ThingMagic One Broadway Cambridge, MA 02142 USA Phone: (617) 758-4177 EMail: margaret@thingmagic.. com Jason Goldschmidt Sun Microsystems M/S UMPK17-103 17 Network Circle Menlo Park, CA 94025 USA Phone: (650) 786-3502 Fax: (650) 786-8250 EMail: jason.. goldschmidt@sun.. com Aldrin Isaac Bloomberg L.. 499 Park Avenue New York, NY 10022 USA Phone: (212) 940-1812 EMail: aisaac@bloomberg.. com Tim Chown School of Electronics and Computer Science University of Southampton Southampton SO17 1BJ United Kingdom EMail: tjc@ecs.. uk Bound Informational [Page 15] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 Jordi Palet Martinez Consulintel San Jose Artesano, 1 Madrid, SPAIN Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 EMail: jordi.. palet@consulintel.. es Fred Templin Nokia 313 Fairchild Drive Mountain View, CA 94043 USA Phone: (650) 625-2331 EMail: ftemplin@iprg.. nokia.. com Roy Brabson IBM PO BOX 12195 3039 Cornwallis Road Research Triangle Park, NC 27709 USA Phone: (919) 254-7332 EMail: rbrabson@us.. ibm.. com Bound Informational [Page 16] RFC 4057 IPv6 Enterprise Network Scenarios June 2005 Full Copyright Statement Copyright (C) The Internet Society (2005).. Bound Informational [Page 17]..

    Original link path: /publications/standards/rfc4057.txt
    Open archive


  • Archived pages: 75