Nathan Lutchansky | 1 Jan 17:29 2011

Re: ULA as PREF64

[resent with the correct from-address]

On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote:
> Are there any known limitations or problems with using ULA addresses
> as the PREF64?
> 
> I do not want people from outside of my administrative domain to use
> my DNS64 and NAT64.  Other mechanisms such as access lists will be
> used, but in an attempt to have a layered approach to this particular
> security issue, it seems to make sense that ULA be used as both the
> queried address of the DNS64 as well as the NSP PREF64 that will be
> used.
> 
> Any concerns that i am overlooking?

There might be some considerations concerning address selection.  RFC
3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA
addresses to be of global scope, but some implementations (e.g. glibc)
deviate from this and consider it to be of site-local scope.  This means
that the hosts on your network with both native IPv4 and NAT64
connectivity would prioritize one protocol over the other in an
implementation-dependent way.

From a more practical viewpoint, you may run into trouble with customer
equipment firewalling ULAs by default on the WAN interface.

Is there a reason you can't use the non-routable well-known prefix
64:ff9b::/96?  Traffic engineering?  -Nathan
Cameron Byrne | 1 Jan 18:06 2011
Picon

Re: ULA as PREF64

On Sat, Jan 1, 2011 at 8:29 AM, Nathan Lutchansky
<lutchann-behave <at> litech.org> wrote:
> [resent with the correct from-address]
>
> On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote:
>> Are there any known limitations or problems with using ULA addresses
>> as the PREF64?
>>
>> I do not want people from outside of my administrative domain to use
>> my DNS64 and NAT64.  Other mechanisms such as access lists will be
>> used, but in an attempt to have a layered approach to this particular
>> security issue, it seems to make sense that ULA be used as both the
>> queried address of the DNS64 as well as the NSP PREF64 that will be
>> used.
>>
>> Any concerns that i am overlooking?
>
> There might be some considerations concerning address selection.  RFC
> 3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA
> addresses to be of global scope, but some implementations (e.g. glibc)
> deviate from this and consider it to be of site-local scope.  This means
> that the hosts on your network with both native IPv4 and NAT64
> connectivity would prioritize one protocol over the other in an
> implementation-dependent way.
>

That's an interesting point, but it works in any case still, right?
Regarding what is in place today in the address selection space across
implementations, the only think that is consistent is the expectation
that it will be inconsistent.  That said, i prefer single stack
(Continue reading)

Nathan Lutchansky | 3 Jan 17:25 2011

Re: ULA as PREF64

On Sat, Jan 01, 2011 at 09:06:01AM -0800, Cameron Byrne wrote:
> On Sat, Jan 1, 2011 at 8:29 AM, Nathan Lutchansky <lutchann-behave <at> litech.org> wrote:
> > On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote:
> >> Are there any known limitations or problems with using ULA addresses
> >> as the PREF64?
> >
> > There might be some considerations concerning address selection. ?RFC
> > 3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA
> > addresses to be of global scope, but some implementations (e.g. glibc)
> > deviate from this and consider it to be of site-local scope. ?This means
> > that the hosts on your network with both native IPv4 and NAT64
> > connectivity would prioritize one protocol over the other in an
> > implementation-dependent way.
> 
> That's an interesting point, but it works in any case still, right?

Well, the traffic should still go *somewhere*, but possibly not to where
the owner/manufacturer of the device intended.

I can imagine that handset manufacturers may set up their address
selection rules to always prefer site-scoped addresses.  The reason
being that carriers might run split-DNS for their internal services, so
that devices on their own network could be directed to a customers-only
version of the service running on site-local addresses.  (I think the
T-Mobile "My Account" app for Android works something like this.)

Now imagine a handset with both a GPRS data link to your IPv6-only APN
and an active WiFi connection to an IPv4-only network.  If DNS queries
go to the GPRS link, and all queries for IPv4-only hosts are answered
with a site-scoped address, no IPv4 traffic will ever go out the WiFi
(Continue reading)

Cameron Byrne | 3 Jan 18:16 2011
Picon

Re: ULA as PREF64

On Mon, Jan 3, 2011 at 8:25 AM, Nathan Lutchansky
<lutchann-behave <at> litech.org> wrote:
> On Sat, Jan 01, 2011 at 09:06:01AM -0800, Cameron Byrne wrote:
>> On Sat, Jan 1, 2011 at 8:29 AM, Nathan Lutchansky <lutchann-behave <at> litech.org> wrote:
>> > On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote:
>> >> Are there any known limitations or problems with using ULA addresses
>> >> as the PREF64?
>> >
>> > There might be some considerations concerning address selection. ?RFC
>> > 3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA
>> > addresses to be of global scope, but some implementations (e.g. glibc)
>> > deviate from this and consider it to be of site-local scope. ?This means
>> > that the hosts on your network with both native IPv4 and NAT64
>> > connectivity would prioritize one protocol over the other in an
>> > implementation-dependent way.
>>
>> That's an interesting point, but it works in any case still, right?
>
> Well, the traffic should still go *somewhere*, but possibly not to where
> the owner/manufacturer of the device intended.
>

Like always, there is a scope to the technology and testing is
required, that's business as usual for anything the service providers
sells.  It has to work out the door.

> I can imagine that handset manufacturers may set up their address
> selection rules to always prefer site-scoped addresses.  The reason
> being that carriers might run split-DNS for their internal services, so
> that devices on their own network could be directed to a customers-only
(Continue reading)

Nathan Lutchansky | 3 Jan 19:56 2011

Re: ULA as PREF64

On Mon, Jan 03, 2011 at 09:16:27AM -0800, Cameron Byrne wrote:
> On Mon, Jan 3, 2011 at 8:25 AM, Nathan Lutchansky <lutchann-behave <at> litech.org> wrote:
> > Now imagine a handset with both a GPRS data link to your IPv6-only APN
> > and an active WiFi connection to an IPv4-only network. ?If DNS queries
> > go to the GPRS link, and all queries for IPv4-only hosts are answered
> > with a site-scoped address, no IPv4 traffic will ever go out the WiFi
> > link.
> 
> All the handsets i know of don't run multiple interfaces.  For
> example, when Android attaches to WiFi it detaches from GPRS internet
> access, or at least that has been my experience.

The network monitor API in Android allows applications to request that
their traffic leave over a specific outbound link, which means that both
GPRS and WiFi can be active simultaneously under some circumstances.  I
believe Symbian has the same capability.

Android Market insists on having GPRS up for some operations (probably
to get access to carrier-specific sections of the Market) which means
that it breaks horribly when I try to use it on my home WiFi network
with NAT64/DNS64.  I haven't looked into the problem in any detail,
though.

> I believe the issue you discuss is a more broad one for DNS64 clients
> having access to NAT64 resources.

Or, more generally, it's an issue with split DNS of any sort.  -Nathan
Dan Wing | 3 Jan 21:38 2011
Picon

FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05]

> Maybe at this point in the discussion it would be good to hear from
> implementers. There are already tons of NAT44 FTP ALGs out there, I
> wonder how those solve this.

For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's
IOS, and it does nothing special with LANG (it doesn't block the
command nor parse the FEAT response).  We have other ALGs in other
products (e.g., Linksys, ASA), but I did not check those.  Our bug 
database (which spans all Cisco-branded products) has no customer 
complaints about FTP's LANG support.

-d

mohamed.boucadair | 5 Jan 13:49 2011

Multicast IPv4-embedded Address Format

   Dear all,
 
   Various solutions (e.g., [I-D.venaas-behave-v4v6mc-framework],
   [I-D.xu-softwire-mesh-multicast] or [I-D.qin-softwire-dslite-
   multicast]) have been proposed to allow access to IPv4 multicast
   content from hosts attached to IPv6-enabled domains.  Even if these
   solutions have distinct applicability scopes (translation vs.
   encapsulation) and target various use cases, they all make use of
   specific IPv6 multicast addresses to embed an IPv4 multicast address.
   Particularly, an IPv4-embedded IPv6 multicast address is used as a
   destination IPv6 address of multicast flows received from the IPv4-
   enabled domain and injected by the IPv4-IPv6 Interconnection Function
   into the IPv6-enabled domain.  It is also used to build the IPv6
   multicast state (*, G6) or (S6,G6) corresponding to their (*, G4) or
   (S4,G4) IPv4 counterparts by the IPv4-IPv6 Interconnection Function.
 
   Together with Yiu and Jacni, we have edited this I-D to define IPv4-
   embedded IPv6 multicast address format which aims to update RFC4192.
 
   Comments, suggestions and contributions are more than welcome.
 
   Cheers,
 
   Med
********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************
<div>
<div>&nbsp;&nbsp; Dear all,</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; Various solutions (e.g., 
[I-D.venaas-behave-v4v6mc-framework],<br>&nbsp;&nbsp; 
[I-D.xu-softwire-mesh-multicast] or [I-D.qin-softwire-dslite-≤br>&nbsp;&nbsp; 
multicast]) have been proposed to allow access to IPv4 multicast<br>&nbsp;&nbsp; 
content from hosts attached to IPv6-enabled domains.&nbsp; Even if 
these<br>&nbsp;&nbsp; solutions have distinct applicability scopes (translation 
vs.<br>&nbsp;&nbsp; encapsulation) and target various use cases, they all make 
use of<br>&nbsp;&nbsp; specific IPv6 multicast addresses to embed an IPv4 
multicast address.<br>&nbsp;&nbsp; Particularly,&nbsp;<span class="294413912-05012011">an </span>IPv4-embedded IPv6 multicast address is used 
as a<br>&nbsp;&nbsp; destination IPv6 address of multicast flows received from 
the IPv4-<br>&nbsp;&nbsp; enabled domain and injected by the IPv4-IPv6 
Interconnection Function<br>&nbsp;&nbsp; into the IPv6-enabled domain.&nbsp; It 
is also used to build the IPv6<br>&nbsp;&nbsp; multicast state (*, G6) or 
(S6,G6) corresponding to their (*, G4) or<br>&nbsp;&nbsp; (S4,G4) IPv4 
counterparts by the IPv4-IPv6 Interconnection Function.</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; Together with Yiu and Jacni, 
we have edited this I-D to define IPv4-<br>&nbsp;&nbsp; embedded IPv6 multicast 
address format<span class="294413912-05012011"> which aims to update 
RFC4192</span>.</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; Comments, 
suggestions and contributions are more than welcome<span class="294413912-05012011">.</span>
</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; Cheers,</div>
<div>&nbsp;</div>
<div>&nbsp;&nbsp; Med</div>*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
</div>
Iljitsch van Beijnum | 5 Jan 15:19 2011

Re: FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05]

On 3 jan 2011, at 21:38, Dan Wing wrote:

> For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's
> IOS, and it does nothing special with LANG (it doesn't block the
> command nor parse the FEAT response).  We have other ALGs in other
> products (e.g., Linksys, ASA), but I did not check those.  Our bug 
> database (which spans all Cisco-branded products) has no customer 
> complaints about FTP's LANG support.

Apparently nobody else can muster up the energy to care about this.

I'm ok with adding a SHOULD for supporting LANG in the ALG so that if a server and client negotiate a
non-default language the ALG also participates. This assumes the ALG supports the negotiated language,
but I'm thinking that if the server and client support a non-default language, there's a good chance that
the ALG vendor either added this language too, or allowed sufficient customization for the user to do
this. The ALG only has 10 or so responses that it can generate, after all.

But for the reasons I outlined earlier, I'm still very reluctant to make this a MUST. Seeing as the FTP44 ALG
people apparently managed to do without this, such a requirement runs a big risk of becoming a dead letter,
anyway. There's enough of that when it comes to FTP specifications...

Iljitsch
Dave Thaler | 5 Jan 17:11 2011
Picon

Re: FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05]

Question to FTPEXT:

Given that many NAT44's that have FTP ALG don't allow LANG to work correctly,
and we haven't seen any responses from FTPEXT folks arguing that it's
important, should the Behave WG consider LANG support in RFC 2640 to be 
unimportant?  Is it basically dead?

If so, I'm fine with a SHOULD in the FTP64 doc.   And I agree with Iljitsch's
implication that the recommendation for FTP64 ALGs should be the same
as whatever the recommendation for other FTP ALGs (e.g. in NAT44's) is.

-Dave

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch <at> muada.com]
> Sent: Wednesday, January 05, 2011 6:19 AM
> To: Dan Wing
> Cc: Dave Thaler; draft-ietf-behave-ftp64 <at> tools.ietf.org; ftpext <at> ietf.org;
> 'Behave WG'
> Subject: Re: FTP64 LANGuage [was RE: [BEHAVE] one week WGLC, draft-ietf-
> behave-ftp64-05]
> 
> On 3 jan 2011, at 21:38, Dan Wing wrote:
> 
> > For whatever it's worth, I checked the FTP ALG for NAT44 in Cisco's
> > IOS, and it does nothing special with LANG (it doesn't block the
> > command nor parse the FEAT response).  We have other ALGs in other
> > products (e.g., Linksys, ASA), but I did not check those.  Our bug
> > database (which spans all Cisco-branded products) has no customer
> > complaints about FTP's LANG support.
> 
> Apparently nobody else can muster up the energy to care about this.
> 
> I'm ok with adding a SHOULD for supporting LANG in the ALG so that if a server
> and client negotiate a non-default language the ALG also participates. This
> assumes the ALG supports the negotiated language, but I'm thinking that if the
> server and client support a non-default language, there's a good chance that the
> ALG vendor either added this language too, or allowed sufficient customization
> for the user to do this. The ALG only has 10 or so responses that it can generate,
> after all.
> 
> But for the reasons I outlined earlier, I'm still very reluctant to make this a
> MUST. Seeing as the FTP44 ALG people apparently managed to do without this,
> such a requirement runs a big risk of becoming a dead letter, anyway. There's
> enough of that when it comes to FTP specifications...
> 
> Iljitsch
Fred Baker | 5 Jan 20:32 2011
Picon

Re: FTP64 LANGuage [was RE: one week WGLC, draft-ietf-behave-ftp64-05]


On Jan 5, 2011, at 8:11 AM, Dave Thaler wrote:

> I agree with Iljitsch's implication that the recommendation for FTP64 ALGs should be the same as whatever
the recommendation for other FTP ALGs (e.g. in NAT44's) is.

Yes.

Gmane