Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

[Tom Taylor <[e-mail]>]

Agreed, we shouldn't be fragmenting our efforts.

If that is acceptable to you, Kawamura-san?

Tina TSOU wrote:
> It can also be part of the draft-lee-v4tov6transition-problem-statement, 
> which we are working on.
> 
> 
> B. R.
> Tina
> http://tinatsou.weebly.com/index.html
> ----- Original Message ----- From: "Fred Baker" <[e-mail]>
> To: <[e-mail]>
> Sent: Tuesday, August 17, 2010 2:59 PM
> Subject: Re: draft-arkko-ipv6-transition-guidelines WGLC
> 
> 
> Thanks very much, Kawmura-san. As you say, some of these questions are 
> not worthy of an operator, but many are important to all of them. If we 
> can get all of the questions on the table, I'm sure we can build a draft 
> that we might call an "IPv6 Deployment FAQ". I wonder if you would be 
> willing to co-author it with me?
> 
> On Aug 16, 2010, at 9:49 PM, Seiichi Kawamura wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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 [e-mail] if we have not, read the document, and 
>>> comment on it on [e-mail] 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 [e-mail] prior to that.
>>>
>>> Begin forwarded message:
>>>
>>>> From: Fred Baker <[e-mail]>
>>>> Date: August 15, 2010 11:00:04 AM PDT
>>>> To: [e-mail]
>>>> Cc: [e-mail], [e-mail]
>>>> 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-----
> 
> 
> 
> 
>