Subject: [BEHAVE] 6to4 and port-restricted IP addresses

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Dec 2008 09:40:01 -0800

In thinking about port-restricted IP addresses, the issue and solution
below occurred to me.  Unless there are objections, I'd like to see
something along the lines of text below in the next version of the
port-restricted IP address document(s).

-Dave

---------

Background:
    A port restricted IP addresses relies on a 16-bit port number to
    route packets to the correct destination.  This approach only works
    with transport protocols that contain 16-bit port numbers.  For
    example, it can work with TCP, UDP, and DCCP, but not ICMP in
    general.  Port restricted IP addresses are proposed for both
    Internet gateway devices as well as special-purpose end hosts.
    The point is to provide them with a (fractional) public IPv4 address
    rather than a translated private IPv4 address.

Problem:
    Many Internet gateway devices and end hosts use 6to4 [RFC3056]
    whenever they are provided with an IPv4 address that appears to
    be a public address.  However, 6to4 will not work correctly if
    instead given a port restricted IP address.  Even if native IPv6
    connectivity is provided to such devices, there are still two reasons
    why they would attempt to use 6to4.  First, an Internet gateway
    device may use 6to4 as a way to address and connect native IPv6
    links behind it, to the IPv6 Internet.  Second, a device that
    wants to communicate with a 6to4 destination may prefer using 6to4
    itself in order to avoid going through any 6to4 relays and hence
    minimize path length and latency.

Solution:
    Port restricted IP address proposals already typically assume that
    the same 16-bit port range will be used with multiple independent
    numbering spaces, i.e., TCP port numbers, UDP port numbers, and DCCP
    port numbers.  6to4 can be made to work simply by treating the
    "SLA ID" field in a 6to4 address (see [RFC3056] section 2) in the
    same way.

CPE Behavior:
    When getting a 16-bit range with an IP address, the 6to4 gateway
    MUST assign SLA IDs from this range when constructing subnet prefixes.

ISP Core Router (Port Range Router) Behavior:
    When the IP protocol is 41, a port range router MUST process a packet
    as follows.

    Whenever it would extract a destination port number from incoming
    IPv4 packets, it MUST extract the 16-bit value at offset
    30 bytes into the IPv4 payload (i.e., IPv6 header) and use it
    in the same way as a destination port number.  This is the SLA ID
    portion of the destination IPv6 address.

    Whenever it would extract a source port number from outgoing
    IPv4 packets, it MUST extract the 16-bit value at offset
    14 bytes into the IPv4 payload (i.e., IPv6 header) and use it
    in the same way as a source port number.  This is the SLA ID
    portion of the source IPv6 address.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Dec 2008 10:11:48 +1300

Hi Dave,

Comments in line...

>     MUST assign SLA IDs from this range when constructing subnet prefixes.

Nit: in strict RFC3056 terminology, that's "6to4 router (or 6to4 border router)".

More substantively:

1) I think you need to allow for the case where there are no real subnets.
That will mean faking SLAAC and/or DHCP6 slightly, I suspect, so that each
host believes it's on a different /64 (virtual subnets?). In any case,
you can't announce the same /64 prefix to everybody on the LAN.

2) Where there are real subnets, this will only work if subnet
renumbering is fully automatic, or if everything is static. Are either
of those realistic cases?  Anyway, I don't think it matters too much,
since I hope this particular kludge would only be used short-term for
SOHOs, where a subnet structure is rare.

>     portion of the source IPv6 address.

What about non-6to4 protocol 41 tunnels?? Shouldn't this be done
only for packets where the embedded IPv6 address concerned has
the 2002::/16 prefix? For other tunnels, you can't make any
presumptions about the "SLA ID" bits.

    Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Dec 2008 13:28:10 -0800

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, December 10, 2008 1:12 PM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [BEHAVE] 6to4 and port-restricted IP addresses
>
> Hi Dave,
>
> Comments in line...
>

I didn't follow.  In the Internet gateway device case, there is a
real subnet assigned to the LAN(s) behind the device.

In the single-host case, such hosts already pick an SLA ID in order
to generate a 6to4 address for themselves.  There's no SLAAC or
DHCPv6 they use today.

So maybe I misunderstood your comment.  Please elaborate if so.

> SOHOs, where a subnet structure is rare.

Right, for your home gateways (Linksys, D-Link, Airport Extreme, etc)
generally there's just one subnet behind it anyway, and that's the main
scenario for port-restricted IPs as proposed today.  However, this
solution works as long as the number of internal subnets <= the size
of the port range you get.

When you say "everything is static", we mean the port range assigned
to the customer is just as static as the (fractional) IP address
assigned to the customer.  The result is just as static as a
public IPv4 address is that the ISP would currently assign.
>From the 6to4 router's point of view, the resulting 6to4 space it
uses is just as static as it is today.

> presumptions about the "SLA ID" bits.

I considered that but came to the conclusion that no other protocol 41
tunnels would work without changes to both the CPE and the ISP core router.
Anything wanting to change them would need its own rules in documents.
So the choices for an implementation are to drop all other protocol 41's,
or to not bother checking (which would generally result in being dropped
somewhere anyway).  Given the latter, I'm not sure it's worth it to suggest
ISP core routers verify it's 6to4 when trying to forward at line rate.
Perhaps it's a MAY.

-Dave

---

From: Peter Dambier <[email-masked]>
Date: Wed, 10 Dec 2008 23:23:38 +0100

>> presumptions about the "SLA ID" bits.

I just had a look at my NAT-router. It supports GRE and ESP and
both could be used to tunnel IPv6. Both need all 16 bits.

> ISP core routers verify it's 6to4 when trying to forward at line rate.

Peter

- --
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Dec 2008 11:58:26 +1300

Dave,

>> From: Brian E Carpenter [mailto:[email-masked]]

...
> So maybe I misunderstood your comment.  Please elaborate if so.

Yes, but I'm not very interested in the single host case (where I
agree there is probably no problem that a bit of funny code
can't fix, like not caring which bits are in the SLA ID).

But if I'm doing real 6to4, where the 6to4 border router is
sending out RAs, what do you suggest it puts in bits
48 through 63 of the prefix advertised in the RA? As far as I
understand your proposal, those bits will vary with the port
number in use for each transport session.

    Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Dec 2008 15:08:52 -0800

> Sent: Wednesday, December 10, 2008 2:58 PM
> To: Dave Thaler
> Cc: [email-masked]
> >> That will mean faking SLAAC and/or DHCP6 slightly, I suspect, so
> that
> >> each

No, I suspect you misunderstood the proposal.
Say the ISP assigns the box the IP address 1.2.3.4 with port
range 1024-2047.  That means any IPv4 UDP or TCP endpoints the
device has must use ports in that range.  For 6to4 it means
that it can pick SLA IDs in that range.  So for example it
would use 2002:0102:0304:0400::/64 on one LAN, and
2002:0102:0304:0401::/64 on another LAN.  6to4 works normally
and can carry any IPv6 traffic with whatever transport protocol
and any port.  There's no relationship to the port number
in transport sessions.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Dec 2008 13:43:20 +1300

Got it Dave, thanks.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Dec 2008 19:56:23 -0500

If I understand you, you are speaking about devices that want to
   [ ] - send IPv6 in IPv4 (proto 41) packets as part of 6to4
         transmit process
   [ ] - receive 6to4 (proto 41) packets
   [ ] - both

these devices are behind an IPv4 NAT.

It seems that your solution requires changes to the NAT to support
something special for proto-41, and that you are suggesting that the
port-number equivalent mapping can be done by using the SLAID,
effectively performing a kind of NAT on the IPv6 address inside.

Or did I miss something, and you are suggesting that the NAT might
just blindly apply it's normal TCP rules, and that the SLAID just
happens to be in the right place in the packet....(checking...) no, you
can't mean that, it's very much in the wrong place.

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Dec 2008 14:55:16 +1300

> It seems that your solution requires changes to the NAT

NAT and 6to4 are orthogonal; the ideal CPE would implement
6to4 as a *parallel* function to its NAT44 function. A 6to4
router is not a NAT, and 6to4 doesn't work through a NAT
(hence the need for Teredo).

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Dec 2008 22:44:32 -0500

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:

    Brian> NAT and 6to4 are orthogonal; the ideal CPE would implement
    Brian> 6to4 as a *parallel* function to its NAT44 function. A 6to4
    Brian> router is not a NAT, and 6to4 doesn't work through a NAT
    Brian> (hence the need for Teredo).

  Yes, I agree and concur.  And I understood that is why we have Teredo
(and I run it when I'm not at home where I have native v6..)
  I read Dave's comments as some way to make 6to4 work through a NAT.

  If that's not the problem he was trying to solve, then please explain...

---

From: Peter Dambier <[email-masked]>
Date: Thu, 11 Dec 2008 10:50:10 +0100

>   If that's not the problem he was trying to solve, then please explain...

I guess Dave and Brian are trying to do the same I want:

Replace that NAT44 obstacle by something better.

a great NAT66 router would replace that NAT44 and give us ISATAP, 6to4
and native IPv6.

Thinking of a crippled (port restricted) IPv4 world:

1) it would be great for the music industry. Now they could sue two people instead of one.

2) call the undertaker. No amputation for a dead cow.

Kind regards
Peter

- --
Peter and Karin Dambier

---

From: Dave Thaler <[email-masked]>
Date: Thu, 11 Dec 2008 08:40:26 -0800

This has nothing to do with NAT.

As Brian states, a CPE might be doing NAT44 in parallel to doing 6to4,
but the NAT functionality is not relevant to this thread.  This thread
is about the various proposals discussed in the Behave WG meeting to
give CPEs a fractional IP address as mentioned in the Background of
the email I sent.

-Dave

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Richardson
> Sent: Wednesday, December 10, 2008 7:45 PM
> To: [email-masked]

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Dec 2008 10:46:01 -0800

> (and I run it when I'm not at home where I have native v6..)

He's trying to make 6to4 work through a particular kind of service- 
provider NAT, for which some closely related [and potentially  
mergeable] proposals are on the table in SOFTWIRE, e.g. dual-stack  
lite and a+p borrowing.  The NAT in this scenario would be interposed  
between the 6to4 CPE router and the 6to4 relay router.  In fact, with  
dual-stack lite, the SP-NAT could also *be* the 6to4 relay router.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Rémi Després <[email-masked]>
Date: Fri, 12 Dec 2008 11:19:52 +0100

Dave,

1) IThe idea of specifying how one more v4 application can deal with 
port restricted v4 addresses, in this case the 6to4 IPv6 encapsulation 
in v4 packets, is IMO very valuable.

2) As suggested by Brian, Port Range Routing in  6to4 border routers  
should act as proposed, on an incoming packet,  ONLY IF the protocol 41 
encapsulated packet does contain a 6to4 destination address.

This is IMO important to ensure upward compatibility with all future 
mechanisms that may use encapsulation in v4 packets. Actually, there is 
already one such mechanism in operation, namely 6rd which Free.fr used 
to deploy native IPv6 behind its CPEs (draft-despres-6rd-02.)

3) Regarding the source address choice within a host, between native 
IPv6 and 6to4 when both are possible:

- I suggest to restrict the choice of 6to4 ONLY IF the remote host has  
ONLY a 6to4 address : if both hosts have native addresses,  they SHOULD 
use them, even if they have also 6to4 addresses.

- I didn't understand the first reason given to justify 6to4 source 
addresses ("an Internet gateway device may use 6to4 as a way to address 
and connect native IPv6 links behind it, to the IPv6 Internet"). Could 
you be more explicit?

4) In the CPE  Behavior, I suggest to add something like:
"The 16-bit SLA ID must be outside any subsets of available port range 
that the CPE sub-assigns to other functions. Examples of such functions  
include  a CPE NAT44, and assignment by the CPE to hosts behind it of 
the same v4 address but with further restricted port ranges.

Best regards,
RD

Dave Thaler  -  le (m/j/a) 12/10/08 6:40 PM:.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 12 Dec 2008 14:20:40 +0200

> dual-stack lite, the SP-NAT could also *be* the 6to4 relay router.

Considering that this SOFTWIRE proposals _require_ cooperation between the CPE 
and the ISP NAT, why would we use 6to4 anyway? Can we not have some dedicated 
proto-41 or UDP _point-to-point_ tunneling, more like "6to4rd". That should 
provide more control to control-freak ISPs and be more reliable, by virtue of 
not depending upon third party relays.

IMU, 6to4 is all about providing IPv6 to users without ISP cooperationg.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 12 Dec 2008 07:47:55 -0800

> Behalf Of Rémi Després
> Sent: Friday, December 12, 2008 2:20 AM
> To: Dave Thaler
> Cc: [email-masked]

Yes, but 6RD in general doesn't have 16-bits available for subnetting.
If the ISP has a /17 or longer native IPv6 prefix, 6RD can't work with
a port-restricted IP anyway (it doesn't matter what you do since the
ISP cannot deploy both 6RD and port-restricted IPs)
.
If the ISP manages to get a /16 native IPv6 prefix, 6RD can
work and the relevant 16-bits would be in the same place as 6to4.

If the ISP somehow manages to get a /16 or shorter native IPv6 prefix,
6RD can work, and you have more than 16-bits of subnetting space.  The
16 bits in the same position as 6to4 can be used in the same way
for each /16.

So I don't see the value in requiring verifying the address is 6to4.
As I mentioned to Brian, I consider it a MAY.

> use them, even if they have also 6to4 addresses.

That's already specified in RFC 3484.
No need to say anything about this in my view (and this isn't specific
to port-restricted IP's either).

> and connect native IPv6 links behind it, to the IPv6 Internet"). Could

An IGD has to get a /64 it can advertise on each LAN behind it.
There's two ways it can do this:
a) DHCP Prefix Delegation, if supported by the ISP
b) use a 6to4 prefix, if given a public IPv4 address by the ISP

The first reason applies when (a) is either not available or costs
the customer more than (b).

---

From: Dave Thaler <[email-masked]>
Date: Fri, 12 Dec 2008 07:53:36 -0800

> Behalf Of Rémi Denis-Courmont
> Sent: Friday, December 12, 2008 4:21 AM
> To: [email-masked]
> and the ISP NAT, why would we use 6to4 anyway?

I answered that in my original email.  Either
a) The CPE uses 6to4 for addressing a connected network (e.g.
   because DHCP-PD is not available or is more expensive than
   using 6to4 space), or
b) Because it wants to talk to 6to4 destination addresses more
   efficiently (without relays, shorter path length/latency)

> Can we not have some
> dedicated

6to4 requires no changes to the ISP core router except what I
mentioned, which is equivalent to what they would already have
to do for TCP and UDP if they want port-restricted IPs.

What you propose is more complex (and hence expensive).

> IMU, 6to4 is all about providing IPv6 to users without ISP

Not necessarily.  There are ISPs (BT was one I believe) that have
use(d?) 6to4 for quite some time for the same scenario that Free
uses 6RD for now.

-Dave

---

From: Rémi Després <[email-masked]>
Date: Mon, 15 Dec 2008 12:14:06 +0100

Dave,

Thanks for the detailed answer.

Further comments below.

RD

Dave Thaler  -  le (m/j/a) 12/12/08 4:47 PM:

-----Original Message-----

Dave,

Yes, but 6RD in general doesn't have 16-bits available for subnetting.
If the ISP has a /17 or longer native IPv6 prefix, 6RD can't work with
a port-restricted IP anyway

A 6rd address being native IPv6 is not concerned itself with indicating
a port restriction.

But your point leads to an interesting remark: a 6rd ISP should provide
to its customers, in addition to the 6rd prefix, a 6to4 prefix . Thus,
if one of its  6rd AND 6to4 host has to communicate with a remote host
that has 6to4 IPv6 but no native IPv6, it will use its 6to4 source
address. The gain is that the IPv6 routing path to the remote host will
then be guaranteed to be available (while, as we know, the routing path
from native IPv6 to 6to4 exists in many cases, but isn't guaranteed to
exist).

(it doesn't matter what you do since the
ISP cannot deploy both 6RD and port-restricted IPs)

As indicated in 4.1 of draft-despres-6rd-02 (and in previous drafts on
6rd), an ISP can indeed deploy 6rd on an infrastructure where routing
is based on RFC1918 private IPv4 addresses.

This is BTW one of the applications of SAM (e.g. section 4.2.1 of
draft-despres-sam-01:  both native IPv6 a la 6rd and restricted port
global Pv4 are made available across an RFC1918 mobile operator
infrastructure).

.

See first comment.

Suggesting to have, in running code, some arbitrary restrictions that
will prevent future use of a general mechanism is, IN GENERAL, a very
bad standardization practice.

IMO, this is NOT a minor point.

If 6to4 relay functions would be permitted to discard packets they are
not concerned with, several clean and simple mechanisms may become
impossible,  with an unfortunate approval by IETF.

If I miss something, please let me know.

IMO, the problem is that your problem statement was ambiguous on this
point.

It suggests that the host finds reasons to "attempt"  6to4.

If it means departing from RFC 3484 address selection rules, then it's
worth to be as specific as possible  on when departing is suggested
(hence my suggestion).

If it only means applying  RFC 3484 (i.e. use 6to4 as source address if
you have one and if the remote host has IPv6 but only in 6to4), then
there in my understanding is no more need to write what you wrote than
to write my suggested clarification.

Note: there is a case c): in sites where CPEs are provided by the ISP.
Other means than DHCP prefix delegation are available to them
(typically, parameter downloads together with software downloads).

The confusion might come from the sentence which introduces the two
reasons ("Even if native IPv6 connectivity is provided to such
devices, there are still two reasons...").

Best regards,
RD

In thinking about port-restricted IP addresses, the issue and

solution

-Dave

---------

Background:
A port restricted IP addresses relies on a 16-bit port number to
route packets to the correct destination. This approach only

works

The point is to provide them with a (fractional) public IPv4

address

Problem:
connectivity is provided to such devices, there are still two

reasons

why they would attempt to use 6to4. First, an Internet gateway
device may use 6to4 as a way to address and connect native IPv6
links behind it, to the IPv6 Internet. Second, a device that
wants to communicate with a 6to4 destination may prefer using

6to4

Solution:
Port restricted IP address proposals already typically assume

that

the same 16-bit port range will be used with multiple independent
numbering spaces, i.e., TCP port numbers, UDP port numbers, and

DCCP

CPE Behavior:
When getting a 16-bit range with an IP address, the 6to4 gateway
MUST assign SLA IDs from this range when constructing subnet

prefixes.

ISP Core Router (Port Range Router) Behavior:
When the IP protocol is 41, a port range router MUST process a

packet

as follows.