Fwd: draft-arkko-ipv6-transition-guidelines WGLC
Fred Baker
http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
"Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
Baker, 12-Jul-10
I gather that the operators on this list are of the opinion that the documents on the table, which include that one and the documents it refers to - especially
http://www.ietf.org/rfc/rfc4213.txt
4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E.
Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes)
(Obsoletes RFC2893) (Status: PROPOSED STANDARD)
but also various other RFCs and Internet Drafts - don't give them the guidance they are looking for. On this list, would it be appropriate to ask operators to tell us what questions remain on the table?
If, for example, operators are looking for a document that describes how to use IPv4/IPv4 NATs to extend the IPv4 domain while the deploy IPv6, so that their customers continue to have some level of IPv4 support during the transition, I wonder to what extent
http://tools.ietf.org/html/draft-ietf-v6ops-incremental-cgn
"An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng
Jiang, Dayong Guo, Brian Carpenter, 18-Jun-10
addresses their questions. I have scheduled it for IPv6 Operations Working Group last Call starting on the 12th of September, but would be happy to see comments on v6...@ops.ietf.org prior to that.
Begin forwarded message:
> From: Fred Baker <fr...@cisco.com>
> Date: August 15, 2010 11:00:04 AM PDT
> To: v6...@ops.ietf.org
> Cc: kur...@kurtis.pp.se, rbo...@juniper.net
> Subject: draft-arkko-ipv6-transition-guidelines WGLC
>
> This is to initiate a two week working group last call of draft-arkko-ipv6-transition-guidelines. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
>
> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
Seiichi Kawamura
Hash: SHA1
Hi Fred
Fred Baker wrote:
> We have a transition guideline in last call in the IPv6 Operations Working Group. Let me take this opportunity to invite all of us to join v6...@ops.ietf.org if we have not, read the document, and comment on it on v6...@ops.ietf.org in the context of that last call.
>
> http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
> "Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
> Baker, 12-Jul-10
>
> I gather that the operators on this list are of the opinion that the documents on the table, which include that one and the documents it refers to - especially
>
> http://www.ietf.org/rfc/rfc4213.txt
> 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E.
> Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes)
> (Obsoletes RFC2893) (Status: PROPOSED STANDARD)
>
> but also various other RFCs and Internet Drafts - don't give them the guidance they are looking for. On this list, would it be appropriate to ask operators to tell us what questions remain on the table?
Here's my answer to this question.
Opertors who have not yet deployed IPv6,
don't know what to do at all. Some want
guidelines like, go and get a /32,
register it in an IRR (if they do so with IPv4),
check if your router supports IPv6, and if not
choose a transition deployment model, route
the prefix, buy transit, and finally bring some server up
so the world can see you that you have IPv6.
This is ISP 101 stuff that any operator should know,
but some request this kind of guidance.
I don't really see value in having a document
that describes all these steps.
However, many operators who have just started and have
at least some knowledge of what IPv6 is, want to know
traps in advance. This I think is quite important.
The differences between IPv4 and IPv6 that everyone stubles through.
I've been asked these same questions over and over again.
How do you assign an address in your network?
(recommended prefix length and value of interface ID)
How do you use link-local?
Is there RFC1918 space in IPv6?
Is there such a thing as secondary address with IPv6?
What's the BGP filtering boundary in IPv6 compimenting the /24 in IPv4?
Is there a filtering guideline for IPv6?
Operators with more experience have more specific thoughts.
Why does OSPFv3 not display global scope address associated with the interface?
Why is VRRPv3's global VIP optional and not implemented by some?
What FIB size should we expect with IPv6?
Are broacasts with IPv4 and ND with IPv6 treated the same way in my L2 switch?
How should be use rDNS with IPv6?
To summarize my long and rough comments (sorry)
"what is the difference between IPv6 and IPv4 that we should be aware of?"
is the question that many tend to ask and is always a popular topic
in my local NOG (JANOG).
Regards,
Seiichi
>
> If, for example, operators are looking for a document that describes how to use IPv4/IPv4 NATs to extend the IPv4 domain while the deploy IPv6, so that their customers continue to have some level of IPv4 support during the transition, I wonder to what extent
>
> http://tools.ietf.org/html/draft-ietf-v6ops-incremental-cgn
> "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng
> Jiang, Dayong Guo, Brian Carpenter, 18-Jun-10
>
> addresses their questions. I have scheduled it for IPv6 Operations Working Group last Call starting on the 12th of September, but would be happy to see comments on v6...@ops.ietf.org prior to that.
>
> Begin forwarded message:
>
>> From: Fred Baker <fr...@cisco.com>
>> Date: August 15, 2010 11:00:04 AM PDT
>> To: v6...@ops.ietf.org
>> Cc: kur...@kurtis.pp.se, rbo...@juniper.net
>> Subject: draft-arkko-ipv6-transition-guidelines WGLC
>>
>> This is to initiate a two week working group last call of draft-arkko-ipv6-transition-guidelines. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
>>
>> We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkxqFPIACgkQcrhTYfxyMkKR8ACeMWWs4R9yi1JO4VGrx5QrG0vV
1lwAn16RYKVoGzEw3zJc67IgdvBH/7t+
=826C
-----END PGP SIGNATURE-----
Fred Baker
Tina TSOU
which we are working on.
B. R.
Tina
http://tinatsou.weebly.com/index.html
Seiichi Kawamura
Hash: SHA1
Getting all the questions on the table seems like
a very big challenge, but I think the "IPv6 Deployment FAQ" idea
is very interesting and helpful. I'm still underexperienced in ID drafting
but if we can work on such a draft, I am interested in coauthoring.
Regards,
Seiichi
iEYEARECAAYFAkxqdf0ACgkQcrhTYfxyMkKOcwCggH4bhVpgT8mSCLWS0+cYsdA/
EhAAoIiBdhcc+Ltf5CvTneIrIahO0Kk+
=jdnB
-----END PGP SIGNATURE-----
Tom Taylor
If that is acceptable to you, Kawamura-san?
Yiu L. Lee
Thanks,
Yiu
> _______________________________________________
> v4tov6transition mailing list
> v4tov6tr...@ietf.org
> https://www.ietf.org/mailman/listinfo/v4tov6transition
Fred Baker
Since I haven't seen a draft of the problem statement, it's hard for me to assess that, and hard for me to contribute to the effort...
Seiichi Kawamura
Hash: SHA1
Hi Yiu, Tom
(Replying to both mails at once)
I don't mind at all.
I haven't seen the problem statement draft
yet so I don't really have a clue if those sets of
specific questions are really relevant to a 'problem statement'.
I'll leave that decision up to you.
Regards,
Seiichi
>> _______________________________________________
>> v4tov6transition mailing list
>> v4tov6tr...@ietf.org
>> https://www.ietf.org/mailman/listinfo/v4tov6transition
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkxrIM8ACgkQcrhTYfxyMkLTXwCfQaGZUSH+VXxyCWabxcB4ub7/
EgQAnixNumh30suuQorJt0eVZbIc6VLJ
=0HRl
-----END PGP SIGNATURE-----
Yiu L. Lee
We are working on it now and will keep you posted.
Thanks,
Yiu
Tina TSOU
All, should I incorporate v4tran...@googlegroups.com directly into
v4tov6tr...@ietf.org?
B. R.
Tina
http://tinatsou.weebly.com/index.html
----- Original Message -----
From: "Brian E Carpenter" <brian.e....@gmail.com>
To: "Tina TSOU" <te...@huawei.com>
Cc: <v4tov6tr...@ietf.org>
Sent: Wednesday, August 18, 2010 6:08 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
> On 2010-08-17 19:12, Tina TSOU wrote:
>> It can also be part of the draft-lee-v4tov6transition-problem-statement,
>> which we are working on.
>
> Just a suggestion, make it draft-lee-v4v6tran-problem-statement.
> If you limit the tag to 8 characters it can also be a BOF name.
>
> Another little team is working on draft-carpenter-v4v6tran-framework.
>
> Brian
>
>
>
>
Yiu L. Lee
Regards,
Yiu
Tina TSOU
You understood the procedures and how to make things easier much more than
us. Brian does also. We see two IETF ex-chairs in this group. I'm so
honoured working with you. I agree with you.
Now, the pieces come into a big picture.
- 1 doc: Problem Statement (Yiu et al are working on it.)
- multiple docs: Individual operator's use cases (Yiu, Can-Can, Lian-Yuan,
Chris, Victor, Julien are working on them)
- 1 doc: v4 to v6 transition framework (Brian et al are working on it.)
- multiple docs: v4 to v6 transition steps/handbooks(should find a better
wording, the answers of the FAQ is one of the inputs)
Just my 2 cents.
----- Original Message -----
From: "Fred Baker" <fr...@cisco.com>
To: <v4tran...@googlegroups.com>
Cc: <v4tov6tr...@ietf.org>
Sent: Wednesday, August 18, 2010 4:51 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
Tina TSOU
Fred Baker
Tina TSOU
v4tov6tr...@ietf.org.
----- Original Message -----
From: "Fred Baker" <fr...@cisco.com>
To: <v4tran...@googlegroups.com>
Tina TSOU
Thank you for asking the question. We had this discussion in the Bar BoF in
Maastricht, people may wanna comment on it. That was initiated from the
discussion with Sheng-Yong, Lian-Yuan and Yiu. I should have invited you to
the Bar BoF, just did not catch you after the talk in mic.
Yes, v6ops WG is one of the most important WGs in IPv6 area. It is also very
busy; usually have 2 sessions of 2 hours for each meeting.
As replied in previous emails, V6OPS is the beginning, which sends the
requirements to 6MAN/BEHAVE/SOFTWIRE. V6Ops focus on issues of deploying
IPv6 into existing IPv4-only networks, with more advanced stages of
deployment and transition a lower priority.
V4TOV6TRANSITION is the end, summarizes and applies the transition
technologies to the existing network. As Sheng-Yong said, in the networks
his company owns, they have solutions for v4 to v6 transition, thought they
need a set of official documents from IETF, to tell the concrete steps for
existing network starting v6, how these transition technologies play
together well, not conflicting to each other, especially for the Day 1 of v4
existing network towards v6. It might
- Solicit issues/concerns from carriers with v4v6 both deployed
- Provide suggestions on technology for solutions
- Define "handbooks (textbook)" for the operations
If possible, a short cycle, fast return, high effectiveness dedicated
"cocktail" forum is needed, apart from heavily loaded WG v6ops. There is no
code change request, if there is, it should go to the other WGs. It will
cooperate with V6OPS/6MAN/BEHAVE/SOFTWIRE.
This is the end of the beginning of v4 existing network to v6!
Now we focus on the docs (problem statement, use case, transition concrete
steps etc.) for Sep 22nd telepresence meeting.
We will have pretty idea after Sep meeting to see if a new WG is created as
a "cocktail" WG in v4 to v6 transition aspect.
BTW, here are some questions through the email discussion these days.
1. From: Seiichi Kawamura <kawamucho at mesh.ad.jp>
How do you assign an address in your network?
(recommended prefix length and value of interface ID)
How do you use link-local?
Is there RFC1918 space in IPv6?
Is there such a thing as secondary address with IPv6?
What's the BGP filtering boundary in IPv6 compimenting the /24 in IPv4?
Is there a filtering guideline for IPv6?
Operators with more experience have more specific thoughts.
Why does OSPFv3 not display global scope address associated with the
interface?
Why is VRRPv3's global VIP optional and not implemented by some?
What FIB size should we expect with IPv6?
Are broacasts with IPv4 and ND with IPv6 treated the same way in my L2
switch?
How should be use rDNS with IPv6?
To summarize my long and rough comments (sorry)
"what is the difference between IPv6 and IPv4 that we should be aware of?"
is the question that many tend to ask and is always a popular topic
in my local NOG (JANOG).
2. From: "Victor Kuarsingh" <Victor.K...@rci.rogers.com>
- The drafts explain many of the technology "whats" but fall short of
describing the "hows"
- Presentation of major (generic) use case network models which exist today,
including network topologies and/or architectures
- Analysis criteria on how to recognize appropriate transition technologies
for the current provider network (such information should/would include
information related to deployed protocols and functions which may assist
and/or hinder various technologies from being deployed)
- How multiple transition technologies can be deployed (simultaneously) for
provider environments where access networks differ and have various
capabilities
- Description of how multiple technologies can co-exist during initial as
subsequent stages of migration (i.e. Moving from IPv4 Only to Dual-Stack to
DS-Lite to NAT64).
- Considerations for legacy operation while moving to IPv6 and related
transition technologies (i.e. many operators will have large caches of IPv4
only equipment which cannot be feasibly upgraded in the near future - like
customer controlled/owned)
- Considerations which need to be made when applying various technologies to
existing networks. Included in this would be impacts to protocols, routing
platforms/systems, security polices, provisioning systems, network services
(i.e. DHCP, DNS etc), law enforcement procedures and more
- Scaling characteristics of deployment modes for each technology model and
intersections during co-existence (i.e. Some of the Network is DS-Lite and
some is Dual Stack).
- BCPs on generic deployment models (how this fits into a network) including
major and key services (i.e. DHCP, DNS)
3. From: "Yiu L. Lee" <yiu...@cable.comcast.com>
if I was running a DSL network, what steps takes me from pure v4 to native
dual-stack?
How to fill the gap of the v4 exhaustion?
If I chose NAT-444, what routing considerations I must consider and what are
the pros and cons?
I know I'm talking to you people now. I'm just a person. So my thought may
not be complete. You are welcome to put things in perspective
----- Original Message -----
From: "Maglione Roberta" <roberta....@telecomitalia.it>
To: "'Tina TSOU'" <te...@huawei.com>; "Fred Baker" <fr...@cisco.com>;
<yiu...@cable.comcast.com>
Cc: <v4tov6tr...@ietf.org>; <jari....@piuha.net>;
<v6...@ops.ietf.org>
Sent: Wednesday, August 18, 2010 4:30 PM
Subject: RE: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
Hi Tina, Yiu and All,
the question I have is why do you think we could not discuss these
issues in v6ops WG?
The current charter of 6vops says:
"The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides operational
guidance on how to deploy IPv6 into existing IPv4-only networks,
as well as into new network installations."
and this in my opinion is exactly what you are talking about in this thread.
Could you please clarify what is different here to require a separate BOF or
new WG?
Thanks and best regards
Roberta
Just my 2 cents.
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.
Scott Brim
> Fred,
> You understood the procedures and how to make things easier much more
> than us. Brian does also. We see two IETF ex-chairs in this group. I'm
> so honoured working with you. I agree with you.
>
> Now, the pieces come into a big picture.
> - 1 doc: Problem Statement (Yiu et al are working on it.)
> - multiple docs: Individual operator's use cases (Yiu, Can-Can,
> Lian-Yuan, Chris, Victor, Julien are working on them)
> - 1 doc: v4 to v6 transition framework (Brian et al are working on it.)
> - multiple docs: v4 to v6 transition steps/handbooks(should find a
> better wording, the answers of the FAQ is one of the inputs)
OK this is finally making sense to me :-)
Fred Baker
On Aug 18, 2010, at 3:49 AM, Tina TSOU wrote:
> Yes, v6ops WG is one of the most important WGs in IPv6 area. It is also very busy; usually have 2 sessions of 2 hours for each meeting.
>
> As replied in previous emails, V6OPS is the beginning, which sends the requirements to 6MAN/BEHAVE/SOFTWIRE. V6Ops focus on issues of deploying IPv6 into existing IPv4-only networks, with more advanced stages of deployment and transition a lower priority.
Donning my crown as Chair IPv6 Operations, and explicitly copying my co-chair and AD...
<crown>
That's actually incorrect; v6ops is about the operation of IPv6 networks. Most IPv6 networks are right now dealing with exactly the issues of deployment in existing IPv4 networks, and so yes operational deployment procedures and clarification of issues is squarely within v6ops' charter. If the reason you wanted to have this as a separate meeting was because you thought you couldn't wedge it into v6ops, you also didn't ask...
If there is a need for a new technology, yes, v6ops sends the work, in the form of requirements, to an appropriate working group. If the question is how to operationally use existing technologies, the discussion will generally stay in v6ops. I have not yet seen the proposed problem statement or other drafts, but from the discussion I would expect this to stay in v6ops.
Personally, I don't see a need for this to be a separate BOF. I'll support the activity wherever it occurs, but if the issue is that the operators would like to have a meeting separate from ongoing v6ops work to discuss the specific issues of deployment and transition, I am capable of and willing to ask for a third slot in Beijing specifically for the purpose. I would need some extra documentation; per the session request tool, "Additional slot may be available after agenda scheduling has closed and with the approval of an Area Director", which means that I need a convincing agenda to show Ron for this to happen. Even with that, in the past IETF there were a lot of working groups that didn't get *second* slots due to schedule density. But yes, it can happen, and I'm willing to make it happen or fit this discussion into the slots v6ops gets if we can't get a third slot.
I'm also willing to take the meeting on September 22nd as a webex-supported interim meeting (as opposed to Telepresence - too many locations) interim meeting of v6ops and let you run it. Due to the rules regarding interim meetings, I have some scurrying to do in the next couple of days - I need to post an announcement 30 days in advance. Doing so makes a very clear IETF footing for the meeting, however.
Up to you. http://www.ietf.org/iesg/bof-procedures.html, and the drop-dead date for a BOF request is 2010-09-13.
Oh, btw - status of documents in v6ops at this instant:
Open, not expected to continue:
draft-azinger-cidrv6-00.txt (probably a replacement draft)
draft-sarikaya-v6ops-prefix-delegation-01.txt
draft-nakibly-v6ops-tunnel-loops-02.txt
Open: draft-troan-multihoming-without-nat66-00.txt
draft-wbeebee-v6ops-ipv6-cpe-router-bis-03.txt
draft-korhonen-v6ops-3gpp-eps-03.txt
draft-jiang-v6ops-nc-protection-01.txt
draft-ietf-v6ops-v6-in-mobile-networks-01.txt
New: draft-vandevelde-v6ops-pref-ps-00.txt
WGLC within August-October:
draft-arkko-ipv6-transition-guidelines-04.txt
draft-ietf-v6ops-tunnel-security-concerns-02.txt
draft-ietf-v6ops-incremental-cgn-01.txt
draft-narten-ipv6-3177bis-48boundary-05.txt (WG awaiting update)
IESG Evaluation:
draft-thaler-v6ops-teredo-extensions-07.txt
draft-ietf-v6ops-ra-guard-06.txt (IESG awaiting update)
draft-ietf-v6ops-rogue-ra-01.txt (IESG awaiting update)
draft-ietf-v6ops-cpe-simple-security-12.txt
draft-gundavelli-v6ops-l2-unicast-03.txt
RFC Editor Queue:
draft-krishnan-v6ops-teredo-update-10.txt
draft-ietf-v6ops-v6inixp-09.txt
draft-ietf-v6ops-isp-scenarios-00.txt
draft-ietf-v6ops-ipv6-cpe-router-07.txt
(http://www.rfc-editor.org/queue2.html#draft-ietf-v6ops-ipv6-cpe-router)
draft-baker-v6ops-greynet-05.txt
The point to take away from this is that while v6ops has had a lot (~24) documents in process over the past few months, many of them are in fact moving on. As of Beijing, I expect to have six or seven (6-7) documents on the table, which is generally what we discuss in a single 2 or 2.5 hour slot. I have already requested two slots, one for 2 hours and one for 2.5.
You may wonder why I spread WGLCs out over time. Basically, it's workload management. I find it easier to get assorted folks to look at documents if I ask them to do so within a finite amount of time (two weeks) one document at a time.
</crown>
Fred Baker
I have no doubt that I will be corrected on numerous points :-)
On Aug 16, 2010, at 9:49 PM, Seiichi Kawamura wrote:
>> On this list, would it be appropriate to ask operators to tell us what questions remain on the table?
>
> Operators who have not yet deployed IPv6, don't know what to do at all.
OK. There's a part of me that suggests that the avenues they have followed for IPv4 will likely serve them well for IPv6 - if they got their IPv4 prefix from APNIC or CNNIC, that might be an obvious place to get an IPv6 prefix, for example. But yes, we can give them some guidelines and some educational references.
> Some want guidelines like, go and get a /32, register it in an IRR (if they do so with IPv4), check if your router supports IPv6, and if not choose a transition deployment model, route the prefix, buy transit, and finally bring some server up so the world can see you that you have IPv6. This is ISP 101 stuff that any operator should know, but some request this kind of guidance. I don't really see value in having a document that describes all these steps.
Yes:
Go to your favorite RIR and get an ISP prefix (default /32, but they want to actually ask for a prefix that will address your current footprint. In short, they will want a prefix for each of their customers, and have guidelines in their RIR's rules (/48 per customer, perhaps /52, /56, or /60 options, please don't assign /64s to networks - they are for LANs). If you need (oversimplifying dramatically, follow the logic not the specific example) a /56 for each of more than 13 million SMB customers (80% of 2^56 / 2^32), don't ask for a /32, ask for a /31 or /30 or whatever you really need. Get enough addresses that you can address all of your present customer base with one prefix. Go back for more at some later time. RFC 3177 suggests that a company's initial allocation should be large enough to handle their business for the readily-foreseeable future.
Do with that prefix pretty much what you did with IPv4...
> However, many operators who have just started and have at least some knowledge of what IPv6 is, want to know traps in advance. This I think is quite important. The differences between IPv4 and IPv6 that everyone stubles through. I've been asked these same questions over and over again.
Question. The European Commission has put together a program called 6DEPLOY; it is 2 a 3 days in-depth on the protocols. Would it make sense for deploying companies to take advantage of it?
The modules can be found in http://www.6deploy.eu/index.php?page=tutorials
An introduction into IPv6: http://www.6deploy.eu/index.php?page=e-learning
> How do you assign an address in your network? (recommended prefix length and value of interface ID)
I think a good place to start with that is
http://www.ietf.org/rfc/rfc4291.txt
4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering.
February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Status:
DRAFT STANDARD)
and
http://www.ietf.org/rfc/rfc3177.txt
3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites.
IAB, IESG. September 2001. (Format: TXT=23178 bytes) (Status:
INFORMATIONAL)
The latter is in the process of being updated:
http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary
"IPv6 Address Assignment to End Sites", Thomas Narten, Geoff Huston,
Rosalea Roberts, 12-Jul-10
Each of the RIRs also has a policy on prefix allocation; they are similar but not necessarily exactly the same. RIPE's is at http://www.ripe.net/docs/ipv6policy.html; can someone (Randy?) supply appropriate links for all of the RIR policies?
The architecture presumes that a /64 is assigned to a LAN subnet, such as an Ethernet or WiFi domain. A recent output from 6man is found at
http://www.ietf.org/rfc/rfc5942.txt
5942 IPv6 Subnet Model: The Relationship between Links and Subnet
Prefixes. H. Singh, W. Beebee, E. Nordmark. July 2010. (Format:
TXT=27035 bytes) (Updates RFC4861) (Status: PROPOSED STANDARD)
and goes into that in some detail.
The architecture presumes that the remaining 64 bits are an endpoint interface identifier. This could be the MAC Address (EUI-64 Address) in an appropriate encoding, or it could be what is called a "privacy address", which is a random number. You will find the most common approach to that, for hosts, in
http://www.ietf.org/rfc/rfc4862.txt
4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten,
T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes
RFC2462) (Status: DRAFT STANDARD)
http://www.ietf.org/rfc/rfc4941.txt
4941 Privacy Extensions for Stateless Address Autoconfiguration in
IPv6. T. Narten, R. Draves, S. Krishnan. September 2007. (Format:
TXT=56699 bytes) (Obsoletes RFC3041) (Status: DRAFT STANDARD)
There is also a DHCP option:
http://www.ietf.org/rfc/rfc3315.txt
3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms,
Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003.
(Format: TXT=231402 bytes) (Updated by RFC4361, RFC5494) (Status:
PROPOSED STANDARD)
That said, there are other options. One might, for example, look at
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6inixp
http://tools.ietf.org/html/draft-ietf-v6ops-v6inixp
"IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano,
15-Jul-10
which suggests that in an Internet Exchange Point one might use an address that helps in debugging routing exchanges. One could also look at what other folks do: guess, for example, who is using the address 2620:0:1cfe:face:b00c::3.
> How do you use link-local?
In general, link-local addresses are only used in well-defined contexts such as MLDv2, routing, and so on. Not that link-local addresses are a bad thing; they are only useful within a local subnet and therefore there isn't a lot of point in allocating DNS names for them, for example. I personally would use them in those places and otherwise forget them.
> Is there RFC1918 space in IPv6?
The counterpart is a Unique Local Address. There is a useful web site that will follow the prescribed algorithm and give you one that is or at least has a high probability of being truly unique.
http://www.ietf.org/rfc/rfc4193.txt
4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman.
October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD)
Something to understand is that at least at this point, NAT as used in IPv4 is not defined and not used in the IPv6 network, and that is generally considered a good thing. If you want a detailed discussion of the reasons, I'll refer you to some of my colleagues. :-)
> Is there such a thing as secondary address with IPv6?
To be honest, there is not a formal definition of a secondary address in IPv4. However, in IPv6, it is normal for an interface to have several addresses - for example, a network that internally uses a ULA and externally has an ISP will have three addresses on every interface - a link-local address, a ULA-based address, and a global address. If you want to consider one of those to be "secondary", be my guest.
> What's the BGP filtering boundary in IPv6 compimenting the /24 in IPv4? Is there a filtering guideline for IPv6?
That is generally an RIR recommendation. Randy or Philip, can I turn to you again for appropriate links?
In general, I think there are two considerations. One is that RIRs allocate prefixes of various lengths, mostly /32 and /48, for specific purposes. You don't want to filter out an RIR assignment - if they are allocating /48 PI space in a given prefix, within that prefix you filter to /48 at the shortest. The other is that deaggregation is generally frowned upon and at the same time generally done. I believe (I may well be wrong though) that ARIN suggests that a /32 prefix be filtered at /36, to allow "reasonable" deaggregation without going crazy. The links Randy suggests will be far better commentary on that, though.
> Operators with more experience have more specific thoughts.
That's why I'm asking Randy or Philip for help here.
> Why does OSPFv3 not display global scope address associated with the interface?
A "why did you make this decision" question might be a better question for the relevant working group. That said, from http://www.ietf.org/rfc/rfc5340.txt
5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July
2008. (Format: TXT=225664 bytes) (Obsoletes RFC2740) (Status:
PROPOSED STANDARD)
2.3. Addition of Flooding Scope
Flooding scope for LSAs has been generalized and is now explicitly
coded in the LSA's LS type field. There are now three separate
flooding scopes for LSAs:
o Link-local scope. LSA is only flooded on the local link and no
further. Used for the new link-LSA. See Section 4.4.3.8 for
details.
o Area scope. LSA is only flooded throughout a single OSPF area.
Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-
area-router-LSAs, and intra-area-prefix-LSAs.
o AS scope. LSA is flooded throughout the routing domain. Used for
AS-external-LSAs. A router that originates AS scoped LSAs is
considered an AS Boundary Router (ASBR) and will set its E-bit in
router-LSAs for regular areas.
On virtual links, a global scope IPv6 address MUST be used as the
source address for OSPF protocol packets.
I think the discussion of scope in OSPF is about the scope of an LSA flood, not the scope of the address. Global scope addresses are in fact mandated in some cases and are certainly supported in all.
If I didn't understand your question, please feel free to ask more particularly.
> Why is VRRPv3's global VIP optional and not implemented by some?
Great questions for the VRRP WG and the vendors in question.
> What FIB size should we expect with IPv6?
That depends. If we enumerate edge networks - if we allocate a PI prefix to every network at the edge - we should expect the size of the FIB to be comparable to the number of edge networks in the world. That looks a lot like 10^7 in not-very-long. That was the point of Marla Azinger's discussion in IETF-78 regarding
http://tools.ietf.org/html/draft-azinger-cidrv6
"CIDR for IPv6: Address Aggregation, Allocation, and Assignment
Strategy", Marla Azinger, Tony Li, Jason Weil, 29-Jun-10
If we enumerate transit networks and have edge networks derive their prefixes from their upstream, using PA addressing, we should expect the size of the FIB to be some small multiple of the number of transit providers in the world (per the CIDR Report, on the order of 5000) plus the size of one's internal network. That varies a lot, of course, but there are ways to aggregate that can materially help.
In essence, that is the point of the locator/id split discussion in RRG, the discussion in
http://tools.ietf.org/html/draft-troan-multihoming-without-nat66
"IPv6 Multihoming without Network Address Translation", Ole Troan, David
Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 26-Jul-10
and the discussions in http://tools.ietf.org/id/draft-mrw-behave-nat66 and
http://tools.ietf.org/html/draft-rja-ilnp-dns
"DNS Resource Records for ILNP", Randall Atkinson, 24-Jun-10
http://tools.ietf.org/html/draft-rja-ilnp-icmp
"ICMP Locator Update message", Randall Atkinson, 24-Jun-10
http://tools.ietf.org/html/draft-rja-ilnp-intro
"ILNP Concept of Operations", Randall Atkinson, 24-Jun-10
http://tools.ietf.org/html/draft-rja-ilnp-nonce
"Nonce Destination Option", Randall Atkinson, 24-Jun-10
I'm going to stop talking before I start a flame war...
> Are broacasts with IPv4 and ND with IPv6 treated the same way in my L2 switch?
Link layer multicast is ignorant of the network layer, apart from behaviors like MLD snooping. IPv4 Multicast and IPv6 Multicast work about the same way, modulo differences related to the address itself. That said, take a look at
http://www.ietf.org/rfc/rfc3306.txt
3306 Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D.
Thaler. August 2002. (Format: TXT=12713 bytes) (Updated by RFC3956,
RFC4489) (Status: PROPOSED STANDARD)
http://www.ietf.org/rfc/rfc3956.txt
3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast
Address. P. Savola, B. Haberman. November 2004. (Format: TXT=40136
bytes) (Updates RFC3306) (Status: PROPOSED STANDARD)
> How should be use rDNS with IPv6?
http://en.wikipedia.org/wiki/Reverse_DNS_lookup. It is essentially as in IPv4, but uses ip6.arpa and enumerates hex rather than decimal digits.
> To summarize my long and rough comments (sorry) "what is the difference between IPv6 and IPv4 that we should be aware of?" is the question that many tend to ask and is always a popular topic in my local NOG (JANOG).
JANOG of course has extensive experience here. I suspect that it also ha a wiki in which it has captured much of this, and if JANOG has not then RIPE, IPNIC, or someone else has.
Fred Baker
http://www.civil-tongue.net/6and4/
Brian E Carpenter
On 2010-08-19 07:45, Hemant Singh (shemant) wrote:
> None of the items in the grocery list below seem to warrant a
> BOF or new WG. V6ops is fully capable and chartered to
> handle this list including not being that busy to not find
> time for the new documents or questions. In fact, just blast
> new drafts to the v6ops mailing list or ask these questions
> of v6ops mailer and folks will reply. If a draft sent to the
> mailer is not being discussed, let the Chairs know and they
> will designate reviewers. In fact some of the questions
> asked can be answered right now.
In my opinion there is an organizational problem that
needs more than just blasting new drafts or asking questions.
Whether it is organized as a separate BOF or a special session
of V6OPS is not so important, but there are many operators who
will soon face IPv6 for the first time and they badly need
organized advice. We will only get that with an organized
discussion.
On 2010-08-19 09:36, Fred Baker wrote:
> there are answers on the table that are available. I do find
> myself thinking "wiki".
I really don't think that meets the need for well organized
advice; no disrespect to http://www.civil-tongue.net/6and4/
or its peers, but neither that nor vendors' documentation
really fills the bill IMHO.
On 2010-08-19 09:53, Cameron Byrne wrote:
> These sound more like training issues that are better handled by ops
> folks, and ops folks generally participate more in groups like NANOG
> and other *NOGs. There are also some very relevant IPv6 operations
> mailing lists that handle tactical issues.
Correct, but again: newcomers to IPv6 need organized documents
first.
>
> As Hermant points out above, most of these questions have straight
> forward immediate answers. Generally, addressing a "HOW" is an
> operator specific issue that depends largely on the context and
> problem to be solve.
Absolutely. I hope nobody imagines we can produce "one size fits
all" documents.
> Also, to be frank, i do not believe the majority of the participants
> in the IETF even work or have current experience at network operators.
Then we'd better get contributions from the minority that do.
Brian
Seiichi Kawamura
Hash: SHA1
Hi Fred
To make it clear, most of those question are not from me
but questions that I tend to hear from a lot of operators
around me. As Brian C. has said in a different mail,
the answers are not organized so I keep hearing the same
questions over and over again.
Rest of my comments inline.
Fred Baker wrote:
> Kawamura-san, I'm going to take a crack at your questions. My reason is, first, to put the answers in one place, but more importantly to point out that there are answers on the table that are available. I do find myself thinking "wiki". I suspect that there are a number of wikis around that encapsulate this information; if not, we can create one at the IETF site.
>
> I have no doubt that I will be corrected on numerous points :-)
>
> On Aug 16, 2010, at 9:49 PM, Seiichi Kawamura wrote:
>>> On this list, would it be appropriate to ask operators to tell us what questions remain on the table?
>> Operators who have not yet deployed IPv6, don't know what to do at all.
>
> OK. There's a part of me that suggests that the avenues they have followed for IPv4 will likely serve them well for IPv6 - if they got their IPv4 prefix from APNIC or CNNIC, that might be an obvious place to get an IPv6 prefix, for example. But yes, we can give them some guidelines and some educational references.
>
>> Some want guidelines like, go and get a /32, register it in an IRR (if they do so with IPv4), check if your router supports IPv6, and if not choose a transition deployment model, route the prefix, buy transit, and finally bring some server up so the world can see you that you have IPv6. This is ISP 101 stuff that any operator should know, but some request this kind of guidance. I don't really see value in having a document that describes all these steps.
>
> Yes:
>
> Go to your favorite RIR and get an ISP prefix (default /32, but they want to actually ask for a prefix that will address your current footprint. In short, they will want a prefix for each of their customers, and have guidelines in their RIR's rules (/48 per customer, perhaps /52, /56, or /60 options, please don't assign /64s to networks - they are for LANs). If you need (oversimplifying dramatically, follow the logic not the specific example) a /56 for each of more than 13 million SMB customers (80% of 2^56 / 2^32), don't ask for a /32, ask for a /31 or /30 or whatever you really need. Get enough addresses that you can address all of your present customer base with one prefix. Go back for more at some later time. RFC 3177 suggests that a company's initial allocation should be large enough to handle their business for the readily-foreseeable future.
>
> Do with that prefix pretty much what you did with IPv4...
Exactly. I guess it might seem hard for some people because
IPv4 networks have been around for a while and many
people have never started up a brand new Interdomain routing
network before. But there's nothing new here and just going
to RIRs will should give you enough information on what to do.
>
>> However, many operators who have just started and have at least some knowledge of what IPv6 is, want to know traps in advance. This I think is quite important. The differences between IPv4 and IPv6 that everyone stubles through. I've been asked these same questions over and over again.
>
> Question. The European Commission has put together a program called 6DEPLOY; it is 2 a 3 days in-depth on the protocols. Would it make sense for deploying companies to take advantage of it?
>
> The modules can be found in http://www.6deploy.eu/index.php?page=tutorials
> An introduction into IPv6: http://www.6deploy.eu/index.php?page=e-learning
I haven't looked at all of these documents, but some of them are actually
pretty good. The addressing case studies is a good reference and
answers some of the questions (although the content needs to be
updated a little... many nitty stuff)
>> How do you assign an address in your network? (recommended prefix length and value of interface ID)
>
> I think a good place to start with that is
>
> http://www.ietf.org/rfc/rfc4291.txt
> 4291 IP Version 6 Addressing Architecture. R. Hinden, S. Deering.
> February 2006. (Format: TXT=52897 bytes) (Obsoletes RFC3513) (Status:
> DRAFT STANDARD)
>
> and
>
> http://www.ietf.org/rfc/rfc3177.txt
> 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites.
> IAB, IESG. September 2001. (Format: TXT=23178 bytes) (Status:
> INFORMATIONAL)
>
> The latter is in the process of being updated:
> http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary
> "IPv6 Address Assignment to End Sites", Thomas Narten, Geoff Huston,
> Rosalea Roberts, 12-Jul-10
I think the addressing case studies
from 6deploy give the best answer to this question.
v6inixp is written very well and reviewed by many engineers from IXPs.
Its a document that is based on reality. Very cool.
The question that comes up these days is, what link-local address would an
connecting ISP assing on their link? We can leave it as EUI, and that's
most likely the default, but one down side to that is, sometimes you have
to look at the neighbor table, and that only shows link local addresses.
You have to go look and see which link local address is associated with
the global address you are peering with.
I set an address like fe80::2518:1 (2518 is my ASNUM).
>
>> How do you use link-local?
>
> In general, link-local addresses are only used in well-defined contexts such as MLDv2, routing, and so on. Not that link-local addresses are a bad thing; they are only useful within a local subnet and therefore there isn't a lot of point in allocating DNS names for them, for example. I personally would use them in those places and otherwise forget them.
Sorry, the question was worded badly.
Its more of a question that asks,
should LL be in my ACL? should I assing static addresses
instead of the automatically generated ones? etc.
>
>> Is there RFC1918 space in IPv6?
>
> The counterpart is a Unique Local Address. There is a useful web site that will follow the prescribed algorithm and give you one that is or at least has a high probability of being truly unique.
>
> http://www.ietf.org/rfc/rfc4193.txt
> 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman.
> October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD)
>
> http://www.sixxs.net/main/
Actually I would answer no to that question.
The technical differences are pretty big at this point.
That includes NAT (just as you say), uniqueness, AS112, etc...
But you can say that if you wanted to use an
address to try in your lab and you don't have global
prefix allocated to you because you are not an LIR,
ULA would be one of your choices.
That would more be like TEST-NET stuff wouldn't it?
> Something to understand is that at least at this point, NAT as used in IPv4 is not defined and not used in the IPv6 network, and that is generally considered a good thing. If you want a detailed discussion of the reasons, I'll refer you to some of my colleagues. :-)
>
>> Is there such a thing as secondary address with IPv6?
>
> To be honest, there is not a formal definition of a secondary address in IPv4. However, in IPv6, it is normal for an interface to have several addresses - for example, a network that internally uses a ULA and externally has an ISP will have three addresses on every interface - a link-local address, a ULA-based address, and a global address. If you want to consider one of those to be "secondary", be my guest.
Agree :-)
>
>> What's the BGP filtering boundary in IPv6 compimenting the /24 in IPv4? Is there a filtering guideline for IPv6?
>
> That is generally an RIR recommendation. Randy or Philip, can I turn to you again for appropriate links?
I've been asking many people "what do you filter at?"
recently. One would think that people filter at /48,
but there are many that filter at /64, some that
filter at exact allocation boudaries, and few that
filter at /32. I don't think we have common religion yet.
The differences in a "full routing table" are pretty
big right now raging from somewher around 1800-3500.
ID Interface State Pri Dead
192.168.2.1 xe-0/0/0.0 Full 1 32
Neighbor-address fe80::2:1
Where's my global address?
>
>> Why is VRRPv3's global VIP optional and not implemented by some?
>
> Great questions for the VRRP WG and the vendors in question.
Yes. I have asked in in the VRRP list, one
person answered that global address support is implicit.
This IMHO should be changed.
I do know about Randy's wiki, and I think it rocks.
Unfortunately, wikis only work locally. They don't
get the global attention that it deserves.
IETF does, which is why I think a discussion here is worthwhile.
Regards,
Seiichi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAkxsgysACgkQcrhTYfxyMkJmbwCgj1ie+RqU0jAW+TOpu/oo9ExB
0nMAn3yAJy4QhxTKsErZ7xVP7VXYqlJW
=Zj0P
-----END PGP SIGNATURE-----
Ed Jankiewicz
http://www.getipv6.info/index.php/First_Steps_for_ISPs
--
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or ed.jan...@sri.com
Fred Baker
ftp://ftpeng.cisco.com/fred/v6ops/transition-diffs.html
ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.txt
ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.xml
If you believe that I have addressed your concerns regarding 4.4 and timing, I'll post that as an update-in-WGLC.
I'll comment on your comments inline.
On Aug 20, 2010, at 9:08 AM, Cameron Byrne wrote:
> On Fri, Aug 20, 2010 at 6:56 AM, Cameron Byrne <cb.l...@gmail.com> wrote:
>> On Sun, Aug 15, 2010 at 11:00 AM, Fred Baker <fr...@cisco.com> wrote:
>>> This is to initiate a two week working group last call
>>> of draft-arkko-ipv6-transition-guidelines. Please read it now. If you find
>>> nits (spelling errors, minor suggested wording changes, etc), comment to the
>>> authors; if you find greater issues, such as disagreeing with a statement or
>>> finding additional issues that need to be addressed, please post your
>>> comments to the list.
>>> We are looking specifically for comments on the importance of the document
>>> as well as its content. If you have read the document and believe it to be
>>> of operational utility, that is also an important comment to make.
>>
>> My feed back is this document, as it stands, is not an operational
>> utility since I do not believe it helps people in operating an access
>> network (most networks have end nodes on them, backbone ISPs know what
>> to do). Do we need yet another anthology of IPv6 tools? I do not
>> think there is good reason that this document should move forward
>> since it does not add anything new or, IMHO, good advice to people
>> with numbering problems.
>>
You have seen, in the past few days, comments cross-posted to v4tov6tr...@ietf.org; I believe that you are also on that list. This is a set of service providers that are specifically asking the IETF for guidance on how to go about IPv6 deployment and eventual transition. Jari originated this document because he is asked the question, and many of us are.
>> Here are my concerns:
>>
>> 1. The only reason people want to deploy IPv6 is because of IPv4
>> exhaust, right? Yet this document recommends dual-stack as the
>> right approach forward.
May I invite you to look at RFC 4192? You will recall that it was intended to be the first draft of an operational renumbering plan; if someone wants to renumber their network or a part of it, they can look at this for a general structure. I would expect them to draft what I will call a "second draft", that follows the guidelines, addresses the issues raised, and is tailored to their network and its needs.
"Dual Stack" is a renumbering plan, if you will. Instead of renumbering an IPv6 network, it renumbers an IPv4 network as an an IPv6 network. RFC 4192 explicitly addresses business continuity on the existing numbering plane (IPv4 in this case) during deployment, and discusses how one tells whether and when one is ready to shift to the new numbering plan (IPv6 in this case), and ultimately how to turn down the old numbering plan.
I find your remark here confusing. Why would one disrupt one's own business for a network reason? Why would one not seek to continue their business operations during the change? Help me out here.
>> The IETF should know that DS does not solve a
>> numbering problem and there is no incentive for folks to go dual
>> stack. DS is pure altruism to make IPv6 easier to the stragglers and
>> free-riders. But, even technology forward companies like Cisco and
>> Ericsson do not have dual stack websites today, 10+ years after the
>> IETF told everyone they should go DS. So once again, from on high,
>> "do as I say, not as i do".
>>
Actually, we do have some help for IPv4 numbering issues; the translation technology that we have developed in behave and comment on in 4.4 enables a network to carefully husband its IPv4 address space by allocating it (stateless translation) as IPv4-accessible IPv4-embedded IPv6 addresses applied to servers, and deploy ipv6-only clients - historically 40:1 over servers - that can access IPv4 servers using a translation technology not so very different from the IPv4/IPv4 NAT in current wide use. During the IPv6 deployment, there remains a very real question of business continuity; there will be no flag day, which means that there will for a period of time be systems that either have not got IPv4 enabled or whose networks are not IPv6-clean end to end, and this kind of thing can help.
>> 2. If this document is to take a realist view and assert the IETF
>> position as a though leader and guide to the future, it should paint
>> the real picture of IPv4 exhaust and provide real solutions to what
>> happens when there is no more IPv4 to be had. It should also, for
>> historical perspective, explain why DS did not work so people can
>> avoid going down this path.... or at the least, know that going DS is
>> not the end-state where we don't have to worry about IPv4 any more
>> .... DS is just a multi-protocol network that is more expensive and
>> more complicated. In some corners of the world, when i tell people DS
>> does not solve the number problem, it is the first time they have
>> looked at DS with a critical eye.
>>
Which is to say that you have convinced them that they actually have to turn on IPv6, and good for you. Understand that dual stack has not failed for anyone that has tried it. What has failed is "not turning on IPv6".
>> 3.. Fred made it clear that deployment is turning something on.
>> Transition is turning something off. This document is called
>> transition but it does not recommend or articulate how to turn IPv4
>> off in any detail.
>>
I believe that you are referring to the title of the document. the title is "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", not "how to carry out an IPv4 to IPv6 transition". I believe that RFC 5211 gives some thoughts about the latter.
>> 4. Perhaps it would be helpful to specify a scope for this document?
>> Enterprise networks? Access networks? Transit ISPs?
>>
It might be, but here I would be interested in comments from people in those various networks.
In private email, you castigated me for saying anything on IPv6 deployment at all, as in your words "Cisco is not deploying IPv6". I'll repeat for the record the comment I sent in private email.
/*****
* comment from private email
*****/
As you may be aware, Cisco is in the process of internal deployment; IPv6 is deployed in parts of the company, and as I type I am on a phone call related to the deployment itself. That deployment will be dual stack. The reason it is dual stack is that Cisco is not stopping doing business during the transition; we still need to communicate with customers and business partners that have not yet deployed, and world-wide we have roughly 100,000 people that have to do their work during the transition.
When IPv6 has been fully deployed throughout Cisco, a process started a year ago and which I expect will take the coming year, Cisco will start asking the question of IPv4 turn-down. That will not be a technical decision; it will be a business decision. One by one, I would expect Cisco to temporarily and then permanently disable IPv4 access to various internal applications. When Cisco has no more internal applications running that use IPv4, the only real use of IPv4 in Cisco will be access to the outside world. At some point, I would expect Cisco to determine that the business need to use IPv4 to do that has diminished, and IPv4 support is no longer needed.
Very honestly, the turn-down process is not a priority for Cisco. The equipment and configurations required for IPv4 are sunk cost, and the bandwidth is essentially the same whether IPv4 or IPv6. I expect the turn-down process to take as long as is necessary, and probably a lot longer.
Who am I to tell people to do dual stack? Someone who is doing dual stack, and whose corporate share-holders and management will consider nothing else.
/*****
*****/
If I am incorrect, I know someone will correct me; my guess is that the fundamental needs of enterprise, access, and transit networks are roughly the same, although they are discussed and carried out in different ways.
First, we all need enough addresses to run our businesses, whether we are edge networks, access networks, or transit networks.
Not all are feeling the address pinch yet, and a surprising number of edge networks that I talk with don't expect an address pinch at all. The issue of address availability applies to networks that need a flow of address space to deploy new services or meet new customer needs; businesses that don't require addresses to do that don't have that requirement. So when I say that IPv4 addresses are running out, those businesses yawn. For them, the issue that the coming few years impose is one of accessibility to business partners that do have the issue and as a result will deploy. Call that "denial" if you like; it's a viewpoint that I hear expressed.
Any network that does require additional address space from time to time is looking at a continuity of business situation. Not continuity of business with its existing infrastructure, which is paid-in-full, operational, and working, but its new businesses, services, or customer bases. It will deploy IPv6 to meet that new addressing need.
Second, we all need to serve the needs of our customers. Those "customers" may be employees, who need to use the network to access applications relevant to the operation of our own business, or who need to talk with business partners and corporate clients in the course of doing business. They may literally be customers in the case of access networks, or peers in the case of transit networks.
These face a problem - many of their employees or customers require access to the IPv4 Internet in some form while that deployment is happening, and turning up IPv6 requires them to audit their networks (does the current software support what they want to do? If not, do they need new hardware to deploy the needed new software?), prove out new configurations, and turn them up. As you know, that is not a matter of snapping one's fingers. If they had started when they should have, it would literally have been a matter of turning up IPv6 in their existing IPv4 networks; they didn't, and many are now turning to some variation on CGN as described in draft-ietf-v6ops-incremental-cgn to keep IPv4 services stumbling along while they deploy.
You would like us to tell people to, while they are turning IPv6 on, to turn IPv4 off or in their new network zones deploy no IPv4 capability. This doesn't work, due to business continuity. At some point in the future, an IPv6-only service that is not a walled garden will be feasible; today, without IPv4 service, nothing on the IPv4 Internet - by every estimate I see larger than 95% of the Internet - is accessible. I have above given you a very clear view of the implications of that for an edge network; for an access network, selling a service that fails to provide access seems an oxymoron, and for a transit network, it's a dead end. I fail to see how any network, SOHO, SMB, Enterprise, Access, or Transit, is served by failing to meet the needs of its employees or customers.
> 1. Please reconsider explicitly recommending dual stack. Perhaps put
> it some verbiage about "no pain, no gain"
In view of my argument above, what argument should I give that will convince someone to discontinue their current business operation while they deploy IPv6?
> 2. Revise statement about literals. The current unqualified and
> unbounded statement without context gives the wrong impression.
I believe that I have addressed your comments in
ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.txt
I would appreciate your further constructive remarks.
> 3. Squarely face the issue of a fragmented internet where there is
> ipv6.google.com, ipv6.t-mobile.com, www.ipv6.cisco.com
> www.v6.facebook.com as well as aaaa whitelist that Yahoo and Google
> are pushing. I believe the reality of these sites and the DNS
> whitelist are more votes against DS.
http://www.ipv6.cisco.com/, like IPv6.Google.Com and IPv6.Facebook.Com, is indeed IPv6-only. There is a reason, and it has nothing to do with deploying a perfectly usable service. It is to test access to Cisco's public web site using IPv6. What purpose would dual stack deployment have in that context?
In time, I fully expect the deployment of AAAA records for www.cisco.com and its counterparts at the other companies you mention. That will not be a "trial" scenario; it will be a "service" scenario. I think the correct way to read the existence of sites like these that are IPv6-only and force one to "do something different" to get to them is that the companies don't yet consider them to be ready for prime time.
Given that, I'm not sure what you are asking me to squarely face. I would, though, invite you to squarely face the business requirements of networks that are deploying in a dual stack configuration.
If you would like, we could jointly look at an RFC 4192 follow-on that discusses the process of transition. I suspect, though, that the "transition" part, the part where we turn down IPv4, will in most places be as it is at Cisco - a business matter. IPv4 will stay up while there is a business need, and will probably stay up for a period of time when there is no remaining real business need "just in case". It will be turned down when its day is simply over.
Fred Baker
On Aug 20, 2010, at 12:10 PM, Cameron Byrne wrote:
> IPv6-only host must emerge as the edge grows (mobile ..., M2M, ...)
I certainly agree with that. Understand that mobile handsets are already and increasingly both IPv4 and IPv6 capable. The issue is in the network, and it is in the applications that those handsets use. The applications like to call gethostbyname() instead of getaddrinfo(), and as a result are IPv4-aware instead of being network layer agnostic. That was Hui Deng's point in the two 3GPP/IETF joint workshops and in the pnat discussion in behave. This document grew out of a powerpoint presentation, pointed to as an informative reference, that I gave at the first of those workshops, and summarizes both that talk and Jari's experience using Ericsson's NAT64 solution at home.
If I were king, and note that I am not at this instant wearing my shiny working group chair crown, I'm wearing my dusty author's beret, gethostbyname would disappear and applications that use it would be given the option of complaining to /dev/null or fixing their code. At some point, maybe the 3G vendors could help us out there...
Yiu L. Lee
> Agreed. The 2x cost is really just the packet core ... which is of
> course a lot of money to double for no tangible benefit ..... talk
> about no business case .... And, still have numbering issues, customer
> experience is the same as IPv4-only + NAT44 and approximately the same
> as IPv6-only + NAT64
>
Life cycle of mobile equipments could be every 2-3 years, but life cycle of
consumer electronics could be 5+ years. Consider many large TVs with
Internet service selling today are still running IPv4-only, fixed line
operators must prepare to support them in foreseeable future.
That said, I am not saying an operator must build a dual-stack core network,
there are technologies such as DS-lite and Softwire Mesh available to run a
pure IPv6 core network with dual-stack edge. All I am saying is the customer
experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, but
the technologies and plan to offer these service are very different.