draft-chen-v6ops-nat64-experience-02

2012-07-06 Thread Aleksi Suhonen
Hi, We've been running a NAT64/DNS64 setup at TREX Tampere Region Exchange for over a year now and I'd like to submit the following experience for your draft: IPv6 Privacy Extensions are a big problem with stateless NAT64. A single device with priv exts enabled will use up several IPv4

Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt

2012-07-06 Thread Bob Hinden
With my co-author hat on, would it help to include a description of what IE supports in Section 3. Web Browsers? Bob On Jul 6, 2012, at 6:01 AM, Brian E Carpenter wrote: Dave, 1) FYI, the deadline we gave the URI list to comment on this has just passed, with only one (positive) reply.

Re: draft-chen-v6ops-nat64-experience-02

2012-07-06 Thread Michael Richardson
Aleksi == Aleksi Suhonen aleksi.suho...@tut.fi writes: Aleksi Within an hour, all the IPv4 addresses in the pool for our Aleksi NAT64 were registered to this one device. Do I understand that you attempt to provide a single IPv4 address 1:1 with a an internal IPv6 address? (NAT vs NAPT)

Re: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt

2012-07-06 Thread Brian E Carpenter
I'd be happy with that, or a small appendix. Dave, is it documented anywhere? Regards Brian On 2012-07-06 15:00, Bob Hinden wrote: With my co-author hat on, would it help to include a description of what IE supports in Section 3. Web Browsers? Bob On Jul 6, 2012, at 6:01 AM, Brian

RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt

2012-07-06 Thread Dave Thaler
-Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Friday, July 06, 2012 6:01 AM To: Dave Thaler Cc: Ole Trøan; ipv6@ietf.org Mailing List; 6man-cha...@tools.ietf.org Chairs; draft-ietf-6man-uri-zon...@tools.ietf.org Subject: Re: 6MAN WG [second]

RE: 6MAN WG [second] Last Call: draft-ietf-6man-uri-zoneid-01.txt

2012-07-06 Thread Dave Thaler
It's documented on the page in my original email. However it's not sufficient. Remember my second piece of feedback was that the document contradicts itself, implying the specified syntax supports cut and paste, but then doesn't provide a section updating RFC 4007 section 11. If the document