Subject: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt

From: Dave Thaler <[email-masked]>
Date: Wed, 16 Mar 2011 22:24:47 +0000

Our charter milestone is:
	Apr 2011 Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std)

This email begins a Working Group Last Call on draft-ietf-behave-v4v6-bih-03.txt
to close on March 30.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Friday, March 11, 2011 2:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] I-D Action:draft-ietf-behave-v4v6-bih-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Behavior Engineering for Hindrance
> Avoidance Working Group of the IETF.
> 
> 
> 	Title           : Dual Stack Hosts Using "Bump-in-the-Host" (BIH)
> 	Author(s)       : B. Huang, et al.
> 	Filename        : draft-ietf-behave-v4v6-bih-03.txt
> 	Pages           : 26
> 	Date            : 2011-03-11
> 
> Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation
> mechanism that allows a class of IPv4-only applications that work through
> NATs to communicate with IPv6-only peers.  The host on which applications
> are running may be connected to IPv6-only or dual-stack access networks.
> BIH hides IPv6 and makes the IPv4-only applications think they are talking
> with IPv4 peers by local synthesis of IPv4 addresses.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-behave-v4v6-bih-03.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the Internet-
> Draft.

---

From: Paco Cortes <[email-masked]>
Date: Thu, 17 Mar 2011 11:23:00 +0100

Hi,

A few comments:

1) Section 4.3, quote "Source addresses: 172.21.112.0/30. Source
addresses have to be allocated because applications use getsockname()
calls and in the BIS mode an IP address of the IPv4 interface has to
be shown ...":
Comment 1a: Should there be a description of the case of a applying
getscockname() to a socket to which a local IPv4 address has already
been bound via bind()? In that case, it should not be an address from
172.21.112.0/30 that should be returned, but the real local IPv4 @
previously bound to the socket, shouldn't it?
Comment 1b: What is the advantage of using a BIH specific address in
other cases? Why not just reusing a real IPv4 address of the host?

2) Section 4.3, quote "Secondary destination addresses:
10.170.160.0/20.  The address mapper will select destination addresses
out of this pool if the node has a dual-stack connection conflicting
with primary destination addresses".
Comment 2a: This does imply that IPv4 peer hosts might have addresses
belonging to the primary destination @ range 172.21.80.0/20 (should be
obvious, but the draft could assume that this might be prohibited in
the RFC1918 network where the host is located).
What shall be the behaviour of a host implementing BIH if the address
mapper has allocated an address from 172.21.80.0/20 (lets take
172.21.80.1 as example) to an IPv6 socket, and later the host tries to
establish an IPv4 socket to an IPv4 peer with exactly that address
172.21.80.1?
Can the BIH implementation somehow distinguish if the local host is
trying to connect to the real IPv4 host with address 172.21.80.1, or
if it is trying to connect to the IPv6 peer to which 172.21.80.1 was
assigned by the address mapper? Seeing a DNS responses with an A
record with address 172.21.80.1 could be used as indication, but it
doesn't really solve the ambiguity. Does this imply that BIH would
fully prevent any communication to a real IPv4 peer with address
172.21.80.1?
If there is a way to distinguish the intended peer, should the BIH
implementation apply NAT44 to the destination to allow communication
(and getting things quite complex...).
The implied limitations and the preferred behavior of a BIH
implementation should be clearly stated.

3) Section 4.3, first paragraph, quote "For example, entries with the
longest inactivity time can be cleared and IPv4 addresses reused for
creating new entries.".
Comment 3a: this seems to imply that address mappings are kept fully
independent from a possible detection of end of communication (like
TCP RST, TCP FIN, ICMP 3, ...). Is this desirable/acceptable?
Shouldn't this proposed standard mandate mechanisms to limit the
liveness of address mappings?

Please bear with me if similar comments were handled in past discussions.

Kind regards,
    Paco

2011/3/16 Dave Thaler <[email-masked]>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 18 Mar 2011 11:11:37 -0700

the draft states:

"The supported class of applications includes those that use DNS for
   IP address resolution and that do not embed IP address literals in
   protocol payloads."

I believe this wording is too strong and makes it sound like BIH
cannot support IPv4 literals, when later in the draft it is stated:

"BIH MAY intercept inet_ntoa() and inet_addr() and use the address
   mapper for those.  Doing that enables BIH to support literal IP
   addresses."

I suggest this wording to make it clear that IPv4 literals may be
supported but embedded addresses with application signalling will pose
 a challenge

"The supported class of applications includes those that use DNS for
   IP address resolution.  Direct references of outbound connections
to IPv4 literals are also may be  support (ex: http://192.0.2.1)."

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 18 Mar 2011 11:20:11 -0700

> This email begins a Working Group Last Call on draft-ietf-behave-v4v6-bih-03.txt

Dave,

Is BIH NAT46?

Generically, host based NAT exist today in many platforms like Linux
and they do not use the API interception structure as in BIH.

IMHO, I believe this implementation on the N900 looks more like what NAT46 is.

http://code.google.com/p/n900ipv6/wiki/Nat64D

And, it provides genuine utility to a user and overcomes real
challenges of the post-IPv4 depletion world.

Regards,
Cameron

---

From: <[email-masked]>
Date: Mon, 21 Mar 2011 11:24:47 +0000

Hi Paco,

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Paco Cortes
> Sent: 17. maaliskuuta 2011 12:23
> To: Dave Thaler; [email-masked]
> Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt
> 
> Hi,
> 
> A few comments:
> 

Do you mean a case where a socket has been explicitly bound to a "real" IPv4 address of a local access network. In such a case the getsockname would have to return that. 

Now a question would be is it ok to transmit packets through BIH if the socket was explicitly bound to a real IPv4 address? Probably the BIH would not perform "source address validation", but the application might mistakenly think it is not traversing through NAT, if the real IPv4 address happened to be from public pool..

> other cases? Why not just reusing a real IPv4 address of the host?

To ensure application understands it is traversing through NAT. 

To ensure there is no conflict between IP addresses used by the BIH and by the access network.

> establish an IPv4 socket to an IPv4 peer with exactly that address

The application might get the 172.21.80.1 by non-DNS means as well, hence even looking at DNS records might not help. 

I see the draft is missing "secondary source addresses", in case the attached network interface is numbered using IPv4 addresses from the same space as currently described.

In the case of BIA, if the Address Mapper happens to have no entry matching the IPv4 address, then the packet should be sent out as IPv4 packet. But once an entry for 172.21.80.1 is created - the packets get translated.

In the case of BIS, if the translator has no entry, the packet gets dropped (unless the system is so wise that it forwards packets to BIS virtual interface only when the packet are sent to addresses there are mappings).

In any case, yes, **it happens sometimes.. Let's look how to document that.
 
> liveness of address mappings?

An application might do series of TCP connections to same destination, i.e.
-> ask IP for name
-> create TCP, close TCP
-> create TCP, close TCP
-> create TCP, close TCP

The lifetime is somewhat difficult to limit, as it should not be shorter than the transport session lifetime... and it is not possible to tell how many connections application makes to the same destination.

You are thinking of tradeoff between the lifetime of mapping and some (same or different) application trying to talk to IPv4 destination having the same address?

> Please bear with me if similar comments were handled in past

There has not been such discussion in the past, so thank you:)

Teemu

---

From: <[email-masked]>
Date: Mon, 21 Mar 2011 11:53:38 +0000

IPv4 literals can be used only after a mapping has been created between IPv4->IPv6. 

So maybe clarify instead (in the appendix section):
--
BIH MAY intercept inet_ntoa() and inet_addr() and use the address mapper for those.  Doing that enables BIH to support literal IP addresses. However, IPv4 address literals can only be used after a mapping entry between the IPv4 address and corresponding IPv6 address has been created.
--
Btw this inet_ntoa/inet_addr text comes from the original BIA, and I have to admit I'm not sure what was the intent of the original authors. For me it seems those functions just do conversion between IPv4 ASCII and IPv4 binary formats (and hence would not necessarily have to be here)... but if the "BIA" would allow IPv6 string formats, then the inet_addr could maybe convert IPv6 textual presentation into IPv4 binary format (and create a new mapping/use existing), but I don't see how inet_ntoa could convert IPv4 address into IPv6 textual presentation without Address Mapper already having an entry for that mapping.

Best regards,

	Teemu

> Behalf Of ext Cameron Byrne
> Sent: 18. maaliskuuta 2011 20:12
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Mon, 21 Mar 2011 13:08:20 +0000

> > Do you mean a case where a socket has been explicitly bound to a
> "real" IPv4 address of a local access network. In such a case the
> getsockname would have to return that.
> 
> [Paco] Then the draft should explicitly say so.

Ok, will clarify. But that kind of binding does not happen without application explicitly binding it's sockets to some address. The implicit binding has knowledge of the destination address, and if the destination is synthetic the socket would be implicitly bound to "BIH address". 

> [Paco] although probably/hopefully very seldom, there might be
> applications with awareness of physical interfaces with several IP
> addresses allocated, and which want to steer which source address is
> used for a specific socket. Something like BIND where it can be
> configured which address to use for zone transfers, for responses, ...

Ok, but in that case application explicitly binds sockets to addresses it wants.

> Such applications would just break if they issue a getsockname() and
> get an unknown address back.

Right, so it is clear that BIH should not change the address a socket has been bound to... but for me that is kind of obvious - at least I don't recall any case where socket address can change after being bound to something.

> It can be questioned if it is "OK" to return the real IPv4 address to
> which the socket was bound despite of it not really being used, but at
> least then the application would try to continue and possibly work.
> On the "mistakenly think it is not traversing through NAT", please see
> my next comment.

If the application asks getsockname() without bind/connect issued, it gets just zero back. If application uses bind() to bind socket to local address, then that's the sockets address and will be returned in subsequent calls. If the application issues connect() without bind() first, then the OS selects source address and if the destination was synthetic IPv4 address, the OS would bind the socket to "BIH address".

> [Paco] I understand that the motivation behind BIH is to support
> legacy applications. For any "legacy" NAT today, the application would
> get a local IP address when using a getsockname(), regardless of NAT
> taking place somewhere else or not. 

Some applications make assumptions that if they have RFC1918 address, they are behind NAT. If they get non-RFC1918 address they usually are not behind NAT (but could be).

> So, that a different new @ is
> returned would only be an indication of using BIH and it would
> therefore only be useful for a new application developed to detect
> BIH. This is fully missing the purpose of IPv6 migration, isn't it?

I may be missing your point.. We are not talking about apps detecting BIH, but apps realizing they may be behind NAT.

Let me put it another way... 

What I was saying is that if your application explicitly binds socket to local public IPv4 address (say 192.0.2.1) and makes a name query for IPv6-only server, for which BIH returns private address (say 172.21.80.1) and then creates connection, it could not realize from its own address (192.0.2.1) that there is NAT between it and the server.

However, if application left socket unbound, and just issued connect to 172.21.80.1, the BIH could implicitly bind the applications's socket to "BIH address" e.g. 172.21.112.1, which application could determine with getsockname, and do realize it is behind NAT.

> [Paco] I agree. Even if DNS is used, it can only be a best guess if a
> later system call is trying to use the "new" 172.21.80.1 got by DNS,
> or the "old" one got from a getsockname().

Ah this case I forgot to reply. This can happen already without BIH so no new from that pow. On multihoming case host can have 192.168.1.2 as its address while on another interface it gets 192.168.1.2 as a pointer to another local host.

Also non-BIH implementing host can move so that first it has on one interface 172.21.80.1 and when joining new WLAN it gets from DNS 172.21.80.1...

With IPv4 and RFC1918 the hosts are just screwed with conflicting addresses - and afaik there is no other working solution than IPv6. 

> [Paco] actually I was assuming that the system had to be so wise.
> Seeing that you have another interpretation, I would say that the
> draft should also be explicit on this.
> I.e., if a BIS implementation MUST, SHOULD, MAY, MUST NOT or SHOULD
> NOT forward packets with a destination address within the ranges
> 172.21.80.0/20 and 10.170.160.0/20 for which there is no entry in the
> Address Mapper. I had assumed a "MUST", but your answer indicates a
> "MAY".

I had not really thought about that case in such detail. The socket layer BIH option is simpler as it can rather easily to "not bump", so there we could have MUST NOT forward if no mapping entry. But the stack layer option is more difficult as the IPv4 packet has already been created and sent, and it has arrived to virtual IPv4 interface. I'm not quite sure if the virtual IPv4 interface can decide not to accept the packet and redirect it to the physical IPv4 interface. Maybe it can do that.. Maybe say the virtual interface SHOULD try to forward the packet to another IPv4 interface in case of no mapping entry?

> [Paco] No, I am thinking of 4096 potential destination addresses
> (172.21.80.0/20) not being sufficient for all potential destinations a
> host might require traffic too between shut downs. A few hours
> intensive web browsing, or a browser configured for pre-fetching of
> content might very quickly reach that limit. The same could apply to
> some peer to peer applications or other applications we have not
> thought of.
> And there is also the issue of hosts not being shut down for weeks.
> The currently described mechanism of just taking the oldest mapping
> sounds very suboptimal to me.

That would require quite a lot of IPv6-only destinations for an IPv4-only app...  But the /20 was just something drawn out of the hat and that would be smaller to avoid conflicts. But I'm definitely ok for increasing the suggest (not mandated!) pool size, just please suggest something.

Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 21 Mar 2011 09:40:30 -0700

> IPv4 literals can be used only after a mapping has been created between IPv4->IPv6.

Is it possible to initiate the mapper without DNS first ?  Why must
DNS be the only trigger?

Cameron

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Mar 2011 11:36:37 -0700

> The lifetime is somewhat difficult to limit, as it should not be
> shorter than the transport session lifetime... and it is not possible
> to tell how many connections application makes to the same destination.

It would be useful to point out in the I-D that some applications 
purposefully do that, so that BIH implementations have the proper
guidance for when to destroy NAT46 state.  As an example, web browsers 
purposefully do not look up the DNS name again, to protect themselves
against DNS rebinding attacks.

-d

> You are thinking of tradeoff between the lifetime of mapping and some
> (same or different) application trying to talk to IPv4 destination
> having the same address?
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Mar 2011 11:38:19 -0700

> Behalf Of [email-masked]
> Sent: Monday, March 21, 2011 4:54 AM
> To: [email-masked]; [email-masked]
> BIH MAY intercept inet_ntoa() and inet_addr() and use the address
> addresses. However, IPv4 address literals can only be used after a
> mapping entry between the IPv4 address and corresponding IPv6 address
> has been created.

That text can't be an accurate description of the BIH deployed by China
Mobile, which works with Skype.  Skype doesn't do DNS queries for
its DHT or for its peers.

So, I believe the "DNS must be used first" restriction doesn't exist.

-d

> --
> Btw this inet_ntoa/inet_addr text comes from the original BIA, and I
> have to admit I'm not sure what was the intent of the original authors.
> For me it seems those functions just do conversion between IPv4 ASCII
> and IPv4 binary formats (and hence would not necessarily have to be
> here)... but if the "BIA" would allow IPv6 string formats, then the
> inet_addr could maybe convert IPv6 textual presentation into IPv4
> binary format (and create a new mapping/use existing), but I don't see
> how inet_ntoa could convert IPv4 address into IPv6 textual presentation
> without Address Mapper already having an entry for that mapping.
> 
> Best regards,
> 
> 	Teemu
>

---

From: Paco Cortes <[email-masked]>
Date: Mon, 21 Mar 2011 13:18:21 +0100

Hi Teemu,
please, see my comments below.

taking place somewhere else or not. So, that a different new @ is

> In any case, yes, **it happens sometimes.. Let's look how to document that.

[Paco] Yes, that was my point. I understand that this problem is
unavoidable as long as RFC1918 @s are used, but I missing a clear
description of the implications.

---

From: <[email-masked]>
Date: Tue, 22 Mar 2011 07:33:07 +0000

Hi Cameron, Dan,

> From: ext Cameron Byrne [mailto:[email-masked]]
> 

and

> From: ext Dan Wing [mailto:[email-masked]]
>

If I recall behave's earlier discussions correctly, it was agreed that the specification developed in behave is to be scoped only for DNS using legacy applications. Hence restriction comes from this WG and that is why BIH draft says what is says. This is not technical restriction, as you can clearly see from implementations (I know of two different).

Would you then like to see some additional text in the section "2.4 Address Mapper" such as:
--
"(4) The Address Mapper MAY also allow creation of mapping table entries via implementation specific means"
--

?

Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 22 Mar 2011 00:59:13 -0700

On Mar 22, 2011 12:33 AM, <[email-masked]> wrote:
> If I recall behave's earlier discussions correctly, it was agreed that the
specification developed in behave is to be scoped only for DNS using legacy
applications. Hence restriction comes from this WG and that is why BIH draft
says what is says. This is not technical restriction, as you can clearly see
from implementations (I know of two different).
> Would you then like to see some additional text in the section "2.4
Address Mapper" such as:

Yes. Why not be more specific as well? This vague language to describe
obvious functionality will be confusing.

Cb

---

From: Paco Cortes <[email-masked]>
Date: Tue, 22 Mar 2011 12:35:09 +0100

Hi Teemu,

> Ok, will clarify. But that kind of binding does not happen without application explicitly binding it's sockets to some address. The implicit binding has knowledge of the destination address, and if…

What do you mean with "if the destination is synthetic the socket
would be implicitly bound to "BIH address"?
Do you mean that if the destination is synthetic, an implementation
shall return also a synthetic source IP address from 172.21.80.0/20
even if the socket was bound at creation to let's say 10.10.10.10?
I believe that there should be no such exceptions for the reasons
already explained.

> Some applications make assumptions that if they have RFC1918 address, they are behind NAT. If they get non-RFC1918 address they usually are not behind NAT (but could be).

Ok, now I get what you meant with understanding it is traversing through NAT.
I was assuming that more often than not the host would already have
RFC1928 addresses on their local interfaces.
For such cases I see no added value on using 172.21.112.0/30
addresses, but just problems potential. But maybe this is an
acceptable compromise if it eases implementations.

> Ah this case I forgot to reply. This can happen already without BIH so no new from that pow. On multihoming case host can have 192.168.1.2 as its address while on another interface it gets 192.168.…

Here I disagree. Without BIH this should never happen unless the
network is completely messed up.
Host are not just multihomed to different RFC1918 networks under
different administrations without NATing or address plan alignment,
and single administrations do not design their networks with
overlapping addresses.

This problem could happen on a wrongly design network, or when
interconnecting devices with hardcoded addresses, but this should not
be a  justification for a new I-D to also create this problem without
highlighting it because it could also occur in other cases.

> I had not really thought about that case in such detail. The socket layer BIH option is simpler as it can rather easily to "not bump", so there we could have MUST NOT forward if no mapping entry. B…

That's ok for me. My concern with the current version of the draft is
that it is not stated at all.

> That would require quite a lot of IPv6-only destinations for an IPv4-only app...  But the /20 was just something drawn out of the hat and that would be smaller to avoid conflicts. But I'm definitel…

My suggestion is not to increase the pool size, but to mandate or at
least recommend the usage of mechanisms to remove unused sessions.
You pointed out that it is not as easy as using TCP RST or TCP FIN due
to recurrent connections to the same address, but this does not
prevent using a timer in addition. And there are a number of well
known and proven mechanism used by NAT devices today.
I would add a  SHOULD or even a MUST in the first paragraph of 4.3
where you write about "smart management techniques of the address
pool".

Sorry about being a bit picky on some requirements. I do understand
that some of the issues I'm commenting are due to the wish to simplify
possible implementations. But as this I-D is intended for the
standards-track as opposed to becoming an informational RFC, I think
that it should meet a high standard.

Paco

---

From: <[email-masked]>
Date: Tue, 22 Mar 2011 14:31:02 +0000

> I believe that there should be no such exceptions for the reasons

I tried to say unbound socket would be bound to BIH address. No touching to already bound sockets addresses.

> acceptable compromise if it eases implementations.

Well, in BIS mode the virtual interface has to have some address on it, right? Maybe you could avoid virtual interface on some implementations, and just "catch" the packets that need to be translated. 

On the other hand, if you would use the physical address of the link, what if the IPv4 on the link dies or renumbers for some reason? That would impact to translated session.

I would leave some room for implementations as well, that is why the draft recommends but not mandates addresses.

> > Ah this case I forgot to reply. This can happen already without BIH
> so no new from that pow. On multihoming case host can have 192.168.1.2
> as its address while on another interface it gets 192.168.1.2 as a
> pointer to another local host.
> 

Please join MIF WG for that discussion. E.g. your cellphone may perfectly connect to WLAN and cellular networks that have different admins and both think it is a good idea to number host as 192.168.1.2.

> highlighting it because it could also occur in other cases.

The big (but not the only) reason current smartphones don't do WLAN and cellular at the same time is overlapping RFC1918 addresses. And it is not because of wrongly designed networks.

> that it is not stated at all.

I will do my best to collect these concerns into the BIH presentation at behave. Then do update.

> where you write about "smart management techniques of the address

That is fine for me as well. Are there some nice reference that describes such techniques?

> that it should meet a high standard.

No prob - the WG doc should reflect WG consensus:) Keep comments rolling in:)

Teemu

---

From: <[email-masked]>
Date: Tue, 22 Mar 2011 14:51:34 +0000

I think the current text in the draft is quite specific:"those that use DNS for IP address resolution and that do not embed IP address literals in protocol payloads ".

This work is limited by the charter:
--
Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std)
--

Hence I don't really see what the more specific text there could be?

I mean we can't describe what the NAT64d actually implements, because it implements features outside of behave WG scope..

Teemu

From: ext Cameron Byrne [mailto:[email-masked]]
Sent: 22. maaliskuuta 2011 09:59
To: Savolainen Teemu (Nokia-MS/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: RE: [BEHAVE] WGLC: draft-ietf-behave-v4v6-bih-03.txt

On Mar 22, 2011 12:33 AM, <[email-masked]<mailto:[email-masked]>> wrote:
> > From: ext Cameron Byrne [mailto:[email-masked]<mailto:[email-masked]>]
> >
> > From: ext Dan Wing [mailto:[email-masked]<mailto:[email-masked]>]
> >

Yes. Why not be more specific as well? This vague language to describe obvious functionality will be confusing.

Cb

---

From: Paco Cortes <[email-masked]>
Date: Tue, 22 Mar 2011 16:57:27 +0100

Hi,
> On the other hand, if you would use the physical address of the link, what if the IPv4 on the link dies or renumbers for some reason? That would impact to translated session.

uhmmm.... you have a point there.

> I would leave some room for implementations as well, that is why the draft recommends but not mandates addresses.

Sounds reasonable.

We started this discussion on the issue of sockets explicitly bound by
an application to a local source IPv4 address at creation time.
On that one we have agreed that the BIH implementation shall respect
that binding and return that IPv4 address instead of a synthetic one
in case of getsockname().
That should then be explicitly documented in the I-D.

For other cases, I see the validity of you argumentation above. I have
then no strong opinion on if the possibility of re-using local IPv4
addresses or synthetic 172.21.112.0/30 ones should be prohibited,
recommended, mentioned as possibility, ...  Whatever you chose is fine
to me ;-)

> Please join MIF WG for that discussion. E.g. your cellphone may perfectly connect to WLAN and cellular networks that have different admins and both think it is a good idea to number host as 192.168…

Point taken.
I still would explicitly mention in the I-D the problem of potentially
preventing communication to real peers using addresses from the
172.21.80.0/20 range, but I do understand now that for the devices for
which this I-D is targeted, this is a known problem..

> That is fine for me as well. Are there some nice reference that describes such techniques?

Maybe just a reference to RFC 2663 will do. References to RFCs 4787,
5382 and 5508 might also be useful.

> No prob - the WG doc should reflect WG consensus:) Keep comments rolling in:)

running out of comments already ;)

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 22 Mar 2011 09:02:03 -0700

On Tue, Mar 22, 2011 at 7:51 AM,  <[email-masked]> wrote:
> I think the current text in the draft is quite specific:”those that use DNS
> for IP address resolution and that do not embed IP address literals in
> protocol payloads ”.
>
>
>
> Hence I don’t really see what the more specific text there could be?
>
>
>
> I mean we can’t describe what the NAT64d actually implements, because it
> implements features outside of behave WG scope..
>

I believe the WG scope and the real world solution scope are 2
different things.  This is a problem. They should be bridged so that
the IETF produces the most relevant standard possible and serves the
reality of what NAT64D on N900 and the China Mobile prototype
exhibit*.  As it stands, this draft only captures a narrow and
unlikely scenario of IPv6-only servers.  I imagine that the
implementations will conclude that session state in a NAT64 is an
IPv6-only server .... otherwise how does Skype work on the China
Mobile prototype of BIH?

For whatever reason, some mobile phone applications fail to operate on
ipv6-only networks.  My sampling shows this can be up to 10% of the
network applications.  It is obvious that NAT46 and NAT64 will have to
be used together to bridge the gap.... either that or "break some
glass" and force the apps to update/fix.  China Mobile and the N900
already have solved this problem with NAT464.  This has already been
demonstrated in 2 unique environments.

I think the time has come for the IETF and BEHAVE to realize that
NAT464 is a reality.  We can plug our ears or see the reality and
document it correctly.

Cameron

*I don't have any idea what China Mobile  has done with BIH, but Dan
mentioned on the list they have a prototype that works with Skype.
Sorry if i have inferred too much and incorrectly.  But, according to
that implementation of BIH, it is NAT464.

> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Mar 2011 11:19:29 -0700

> that implementation of BIH, it is NAT464.

http://code.google.com/p/n900ipv6/wiki/Nat64D says:

 "known success

  ...

  * Skype"

-d

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 22 Mar 2011 11:26:21 -0700

> http://code.google.com/p/n900ipv6/wiki/Nat64D says:

Hmm... i thought you meant that China Mobile had something different
from the N900 code.  My bad.

Cameron

---

From: <[email-masked]>
Date: Thu, 24 Mar 2011 12:50:46 +0000

Hi,

> That should then be explicitly documented in the I-D.

Will do, and also include in the BIH presentation at behave wg.

> which this I-D is targeted, this is a known problem..

Will do that as well.

> 5382 and 5508 might also be useful.

Thank you, will check out those.

Teemu