Skip to main content

IPv6 Guidance for Internet Content Providers and Application Service Providers
RFC 6883

Yes

(Ron Bonica)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Ralph Droms)
(Stewart Bryant)
(Wesley Eddy)

Abstain


Note: This ballot was opened for revision 04 and is now closed.

Ron Bonica Former IESG member
Yes
Yes (for -04)

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -04)

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -04)

                            
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2013-01-11)
Thanks for addressing my DISCUSS
Brian Haberman Former IESG member
No Objection
No Objection (for -04)

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -04)

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -04)

                            
Robert Sparks Former IESG member
No Objection
No Objection (2013-01-07 for -04)
Consider pointing to HELD (RFC5985) as one way to get a more real-time binding between IP address and geolocation.
Russ Housley Former IESG member
No Objection
No Objection (2013-01-04 for -04)
  Please consider the editorial comments provided in the Gen-ART Review
  by Meral Shirazipour on 19-Dec-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg08007.html
Sean Turner Former IESG member
No Objection
No Objection (2013-01-08 for -04)
Not sure if it's worth adding here, but an additional reason to use DNS names and not IP addresses are names in certificates.  If you're putting the IPv4 address in now you also gotta do it for your IPv6 addresses - better to just use DNS names.

Fernando's VPN traffic leakages in dual stack networks draft (draft-ietf-opsec-vpn-leakages-00) might be worth a mention or at least a warning that folks should test to make sure the problem described therein is fixed before blindly accepting that it works.

Pretty please suggest people actually turn security on for the protocols they enable: DNSSEC, DHCPv6 Auth, etc.

s12: r/provid./provided.
Stephen Farrell Former IESG member
No Objection
No Objection (2013-01-08 for -04)
Very readable thanks.

- 5.2, please expand TCAM
Stewart Bryant Former IESG member
No Objection
No Objection (for -04)

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -04)

                            
Martin Stiemerling Former IESG member
Abstain
Abstain (2013-01-09 for -04)
I'm not fully convinced about the usefulness of this draft, as the content is either widely known by folks skilled in the art or you can read it somewhere else or a lot of providers just did it already. Therefore, I am balloting Abstain. 
The draft is probably 5 years late.

Some comments you might consider:

Did this draft receive any input or feedback from any what you call ICP?

Section 1., paragraph 4:

>    Nevertheless, it is important that the introduction of IPv6 service
>    should not make service for IPv4 customers worse.  In some
>    circumstances, technologies intended to assist in the transition from
>    IPv4 to IPv6 are known to have negative effects on the user
>    experience.  A deployment strategy for IPv6 must avoid these effects
>    as much as possible.

  What are those effects?


Section 3., paragraph 2:

>    There is an anecdote of one IPv6 deployment in which prefixes
>    including the letters A to F were avoided by design, to avoid
>    confusing system administrators unfamiliar with hexadecimal notation.
>    This is not a desirable result.  There is another anecdote of a help
>    desk responder telling a customer to "disable one-Pv6" in order to
>    solve a problem.  It should be a goal to avoid having untrained staff
>    who don't understand hexadecimal or who can't even spell "IPv6".

  That are tales but what's the meat?


Section 5.3., paragraph 1:

>    It must be understood that as soon as an AAAA record for a well-known
>    name is published in the DNS, the corresponding server will start to
>    receive IPv6 traffic.  Therefore, it is essential that an ICP tests

  To be precise: An AAAA record does not imply that the IP address
  list in this record is reachable. I.e., the server could receive
  IPv6 traffic if the IPv6 network is setup correctly. Your text
  suggests that setting the AAAA record is just enough.