Subject: [BEHAVE] WGLC prep for 6 documents: interim meeting, Dec 16

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Dec 2009 08:41:25 -0800

As a reminder, we have an interim WebEx teleconference on Wednesday, December
16, at 7am Pacific Time.  The December 16 teleconference will resolve all open
issues with the following documents so they may be immediately WGLC'd (dates
are Behave's milestone dates from our charter):

  Dec 2009 - Submit to IESG:  framework for IPv6/IPv4 translation (info)
  http://tools.ietf.org/html/draft-ietf-behave-address-format
  Dec 2009 - Submit to IESG:  stateless IPv6/IPv4 translation (std)
  http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
  Dec 2009 - Submit to IESG:  stateful IPv6/IPv4 translation (std)
  http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
  Dec 2009 - Submit to IESG:  DNS rewriting for IPv6/IPv4 translation (std)
  http://tools.ietf.org/html/draft-ietf-behave-dns64
  Jan 2010 - Submit to IESG:  IPv6 prefix for IPv6/IPv4 translator (std)
  http://tools.ietf.org/html/draft-ietf-behave-address-format
  Jan 2010 - Submit to IESG:  FTP ALG for IPv6/IPv4 translation (std)
  http://tools.ietf.org/id/draft-ietf-behave-ftp64 
  (currently http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06)

REVIEWERS ARE NEEDED!  Please volunteer to review one, two, or all documents.
WGLC is expected to start on December 17 and end December 31.  To finish WGLC,
we need 5 reviews indicating the document is ready.  One person has
volunteered so far (thanks, Flemming).  If you are willing to review, please
send information to Dan.

Agenda for the interim is at:
  http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart

If you have additional agenda items, which we should discuss to prepare those
documents for WGLC, please email the chairs.

-d

---

From: liu dapeng <[email-masked]>
Date: Sun, 6 Dec 2009 20:19:12 +0800

Hi Dan,

I would like volunteer to review  FTP ALG for IPv6/IPv4 translation
document if it is possible.

Best regards,
Dapeng Liu
2009/12/5, Dan Wing <[email-masked]>:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 6 Dec 2009 06:23:53 -0800

> -----Original Message-----
> From: liu dapeng [mailto:[email-masked]] 
> Sent: Sunday, December 06, 2009 4:19 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] WGLC prep for 6 documents: interim 
> meeting, Dec 16
> 
> Hi Dan,
> 

I added you to
http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart#wglc

-d

> > 16, at 7am Pacific Time.  The December 16 teleconference 
> will resolve all
> > open
> >   (currently 
> http://tools.ietf.org/html/draft-van-beijnum-behave-ftp64-06)
> >
> > WGLC is expected to start on December 17 and end December 
> 31.  To finish
> > WGLC,
> > If you have additional agenda items, which we should 
> discuss to prepare
> > those

---

From: GangChen <[email-masked]>
Date: Tue, 8 Dec 2009 23:49:46 +0800

Hello Dan,

I found the title of "framework for IPv6/IPv4" might have mismatched
hyperlink, which is address format link.

And I would like to review the "framework for IPv6/IPv4" if it is possible.

Thanks

Gang

2009/12/5 Dan Wing <[email-masked]>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Dec 2009 09:14:36 -0800

> From: GangChen [mailto:[email-masked]] 
> Sent: Tuesday, December 08, 2009 7:50 AM
> To: Dan Wing
> I found the title of "framework for IPv6/IPv4" might have 
> mismatched hyperlink, which is address format link. 

Thanks for noticing.  I had actuallly listed address-format twice.  I fixed
that.

> And I would like to review the "framework for IPv6/IPv4" if 

Added.

-d

> discuss to prepare those

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Dec 2009 12:00:44 -0500

>   http://tools.ietf.org/html/draft-ietf-behave-dns64

In http://www.ietf.org/mail-archive/web/behave/current/msg07342.html,
I proposed a change to the text.  As far as I know, that's the only
outstanding issue with the draft as it stands.  I received
(supportive) comments from Brian Carpenter about the proposed change.
I haven't heard anything else.  Unless anyone has any objection, I
plan to go ahead with this.  Ok?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 9 Dec 2009 20:35:18 +0000

Comments on the proposed new text, below...

> 6.3  DNS64 and multihomed and dual-stack hosts
>
> 6.3.1  IPv6 multihomed hosts
>
>    Synthetic AAAA records may be constructed on the basis of the
>    network context in which they were constructed.  If a host has
>    multiple interfaces, it is possible that some of them will receive

s/host has multiple interfaces/host sends queries to DNS resolvers in
multiple networks/

Just because a host has multiple interfaces doesn't necessarily
mean it chooses to send queries on multiple.

Also, the same problem happens if you have a single interface with
two routers on it attached to different networks, and you've managed
to (e.g. manually) configure DNS resolvers from both.  And if you have
two interfaces attached to the _same_ network, then there's no 
real problem treating them both the same.  Hence it's not so much
about having multiple interfaces, but rather being multihomed to
_different networks_.

>    answers from a DNS64 without all of them being connected via a
>    NAT64.  For instance, suppose a system has two interfaces, i1 and
>    i2.  Whereas i1 is connected to the IPv4 Internet via NAT64, i2 has
>    native IPv6 connectivity only.  I1 might receive a AAAA answer from
>    a DNS64 that is configured for a particular NAT64; the IPv6 address
>    contained in that AAAA answer will not connect with anything via
>    i2.
>
>    This example illustrates why it is generally preferable that hosts
>    treat DNS answers from one interface as local to that interface.
>    The answer received on one interface will not work on the other
>    interface.  Hosts that attempt to use DNS answers globally may
>    encounter surprising failures in these cases.  For more discussion
>    of this topic, see [I-D.savolainen-mif-dns-server-selection].
>
> 6.3.2   Accidental dual-stack DNS64 use
>
>    Similarly, suppose that i1 has IPv6 connectivity and can connect to
>    the IPv4 Internet through NAT64, but i2 has IPv4 native transit.
>    In this case, i1 could receive an IPv6 address from a synthetic
>    AAAA that would better be reached via native IPv4 transit.

Again this example would be better described as "network 1" and
"network 2", not "interface 1" and "interface 2".

>
>    Since it is most likely that the host will attempt AAAA resolution
>    first, in this arrangement the host will often use the NAT64 when a
>    native IPv4 would be preferable.  For this reason, hosts with IPv4
>    connectivity to the Internet should avoid using DNS64.  This can be
>    partly resolved by ISPs when providing DNS resolvers to clients,
>    but that is not a guarantee that the NAT64 will never be used when
>    a native IPv4 connection should be used.  There is no
>    general-purpose mechanism to ensure that native IPv4 transit will
>    always be preferred, because to a DNS64-oblivious host, the DNS64
>    looks just like an ordinary DNS server.  Operators of a NAT64
>    should expect traffic to pass through the NAT64 even when it is not
>    necessary.
>
> 6.3.3  Intentional dual-stack DNS64 use
>
>    Finally, consider the case where the IPv4 connectivity on i2 is
>    only to a LAN, with an IPv6-only connection on i1 to the Internet,
>    connecting to the IPv4 Internet via NAT64.  Traffic to the LAN may
>    not be routable from the global Internet, as is often the case (for
>    instance) with LANs using RFC1918 addresses.  In this case, it is
>    critical that the DNS64 not synthesize AAAA responses for hosts in
>    the LAN, or else that the DNS64 be aware of hosts in the LAN and
>    provide context-sensitive answers ("split view" DNS answers) for
>    hosts inside the LAN.  As with any split view DNS arrangement,
>    operators must be prepared for data to leak from one context to
>    another, and for failures to occur because nodes accessible from
>    one context are not accessible from the other.

-Dave