Subject: [shara] "Issues in Port-Restricted IPs" and SAM.A+P

From: Rémi Després <[email-masked]>
Date: Wed, 18 Nov 2009 14:52:23 +0100

Hi all,

At the aplusp BOF, Dave Thaler presented a list of "issues in port  
restricted IPs".
Imposed by the scope of the BOF, strictly limited to A+P for DS-lite,  
it didn't concern other A+P scenarios.
I made the comment that this list, incidentally debatable even for A 
+P/DS-lite, could be useful to analyze other variants of port-range  
extension of IPv4 addresses.

Here are therefore my comments based on:
- Dave's slides, available at www.ietf.org/proceedings/09nov/slides/ 
aplusp-3 - copy attached.
- my SAM.A+P proposal contained in in tools.ietf.org/id/draft-despres- 
softwire-mesh-sam-01 - copy attached.

1. (Slide 2 - Scope)
- SAM.A+P, because it applies to mesh topologies (like those of 6to4,  
ISATAP and 6rd), was out of the BOF scope.
It has therefore been neither presented nor discussed.
- The analysis below is based on Dave's slides used as checklist.

2. (Slide 3 - IP unicast model)
- True, an IPv4 address part of a SAM.A+P locator departs somewhat  
from the classical IP-address model: instead of being the address of  
one and only one interface, it is only used in combination with a  
port prefix, and then identifies a pseudo-interface (as defined for  
6to4 in RFC 3056).
Since no such pseudo-interface participates in any ARP protocol, this  
extension of the IP address model does not conflict with the one-and- 
only-one rule of the IP-address model.
- Note that ND-proxies introduce a different extension of the IP  
model, without this being a big issue: several interfaces, on  
different links, advertise the same address as being theirs.
- Note also that that SAM.A+P, which on one hand extends the IP- 
address model, restores on the other hand the E2E transparency which  
had been broken by NATs.

3. (Slide 4 - bullet 1 - Legacy hosts)
- SAM.A+P cannot, of course, be deployed on legacy hosts.
It provides additional connectivity, but only to hosts that support  
it. (Support is backward compatible, and deployment is incremental).

4. (Slide 4 - bullet 2 - port-specific applications)
- When customer sites can no longer have exclusive IPv4 addresses, no  
application may rely on having any specific port.
This is common to all address sharing schemes.

5. (Slide 5 - bullets 1 and 2 - multiple interfaces, simultaneous or  
successive)
- Hosts that have several interfaces, or that roam from interface to  
interface, cannot expect to have the same port if several such  
interfaces access the Internet via CGNs.
This limitation, due to the IPv4 address shortage per se, is common  
to all address sharing schemes.

6. (Slide 5 bullet 3 - switching back & forth between SAM.A+P and non  
SAM.A+P modes)
- The SAM DHCP option obtained or not for each interface indicates  
clearly which interfaces are SAM.A+P capable and which are not.
- The lack of mobility support is common to all address sharing schemes.

7. (Slides 6 and 7 - Non-port-based protocols)
- The problem of incoming PINGs, and of other port-less protocols, is  
common to all address sharing schemes.
- SAM.A+P hosts that have IPv6 (as they should) can be pinged in IPv6.
- Note that ICMP, which is not port based, has port numbers in its  
error messages (which are the important ones in classical  
applications across the Internet, in particular for MTU determination.

8. (Slide 7 - "Pure-A+P hosts")
- To encapsulate A+P packets, a SAM.A+P host has always, in addition  
to its shared IPv4 address, an interior address in a different  
address family (typically IPv6). "Pure A+Ps" therefore don't exist.  
Hosts always keep a legacy way to communicate, preferably IPv6.

9. (Slide 8 - Provisioning system)
- SAM.A+P, which needs only a new DHCPv6 option, is neither complex  
nor costly.
It is indeed more complex than 6rd, of which it is an extension, but  
not much more, while 6rd is so simple that Free deployed it in 5 weeks.
- SAM.A+P, based on static port-prefix assignments, is not concerned  
with problems of dynamic port range allocations.

10. (Slide 9 - Training/education)
- As discussed above, the extension of the IP-address model is quite  
limited, without interference with ARP.
- Training and education on SAM.A+P is marginal if combined with  
those on CGNs. (Port-prefix extension of addresses, and stateless  
address mappings and encapsulations, that are already familiar with  
6to4, are simple concepts; on the other hand, CGNs issues include  
endpoint independent vs dependent mappings, hair-pinning, various  
ALGs, dynamic port reservations with UPnP and/or NAT-PMP, port- 
reservation limits to avoid DOS attacks, which are much less simple  
matters.)

11. (Slide 10 -  Port randomization)
- If SAM.A+P coexists with CGNs, the SAM draft recommends that DNS  
queries go to the CGN (precisely to have better port randomization,  
and thus mitigate the danger of Kaminsky attacks).
- For maximum security, IPv6 should to be used, in particular to  
reach DNS servers.

12. (Slide 11 - Failure modes
- Discovering all failure modes of NATs and double NATs has been an  
ordeal, as recent Teredo evolutions confirm, and it may not be finished.
- Nothing comparable can be expected with the simple mapping and  
encapsulation logic of SAM.A+P.

13. (Slide 12 -  Long term impact))
- The fact that some people may propose to misuse a new useful new  
tool shouldn't prevent this tool to be available for its normal purpose.
- Concerning NAT66, SAM is precisely a tool that makes NAT66 less  
useful, if useful at all. In particular, it reconciles, in hosts that  
support it, IPv6 private addressing of ULAs, multihoming, and E2E  
transparency.

12 (Slide 13 - Summary)
- SAM.A+P, which only marginally extends the IP model, is simple to  
implement, to document, to deploy, and to maintain.
- While NATs, and cascades of NATs and CGNs, will inevitably continue  
to be deployed, SAM.A+P can contribute to reserve their use to  
scenarios where they are the less harmful.

Regards,

RD

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 19 Nov 2009 19:05:03 +0900

> At the aplusp BOF, Dave Thaler presented a list of "issues in port  

As almost all, if not all, points of his presentation are invalid,
it is a waste of time to discuss on it.

Instead, if you or someone else find some of his points valid, let's
discuss on it.

Do you have some? I have none.

> Imposed by the scope of the BOF, strictly limited to A+P for DS-lite,

DS-lite?

FYI, a large ISP in Japan, maybe the world largest with regard to
the number of subscribers, use private IPv4 space of 10/8 for
its internal topology for years without any problem, which means
we have enough IPv4 address space for ISP internal use.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Nov 2009 19:09:13 +0900

> we have enough IPv4 address space for ISP internal use.

then why are they asking for another /8 and pushing nat444?

randy

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 19 Nov 2009 21:35:02 +0900

> then why are they asking for another /8 and pushing nat444?

Because it is, maybe, the largest ISP in the world and it needs a lot
of IPv4 addresses for their subscribers, which was authorized by
APNIC.

The ISP is assigning two IP addresses for each subsciriber effeciently
not in a way of /30 but two IP addresses from /24 or so.

Anyway, /8 is too large for a single ISP that there is no worrying
about on IPv4 addresses for ISP internal use.

							Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Nov 2009 21:52:17 +0900

> of IPv4 addresses for their subscribers, which was authorized by

they say otherwise.  for one of the 42 layers of nat to avoid conflict
with 10/8 being used by broadband customer

it was not authorized by apnic

> about on IPv4 addresses for ISP internal use.

false

this stuff is hard enough without bullshit

randy

---

From: Rémi Després <[email-masked]>
Date: Thu, 19 Nov 2009 13:56:05 +0100

> Instead, if you or someone else find some of his points valid, let's

As you can note if you read what I wrote, I used Dave's point only as  
a check list to show that, in the particular case of SAM.A+P I work  
on, they are not valid.

>> Imposed by the scope of the BOF, strictly limited to A+P for DS-lite,

Dual-stack lite (for short in the IETF context).
Sorry if you are a video-game fan.

> we have enough IPv4 address space for ISP internal use.

Could you be more specific on how this relates to A+P ?

Regards,
RD

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Nov 2009 06:36:27 +0900

> with 10/8 being used by broadband customer

I thought the number of layers is 666.

Anyway, giving public addresses to customers is a good thing to do,
especially when ISPs are internally using private ones.

Note also that NAT444 can be end to end.

> it was not authorized by apnic

The first /8 was, the second /8 is not.

> this stuff is hard enough without bullshit

As the ISP has a lot of public IP addresses allocated, it can
renumber from private addresses to public ones at will, if internal
use of private IPv4 addresses is any harder than renumbering, which
never occurred.

That is the reality.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 20 Nov 2009 07:01:10 +0900

Remi Despres wrote:

> As you can note if you read what I wrote, I used Dave's point only as  a 
> check list to show that, in the particular case of SAM.A+P I work  on, 
> they are not valid.

That's fine but so obvious.

> Sorry if you are a video-game fan.

My children are.

> Could you be more specific on how this relates to A+P ?

Private IPv4 addresses for ISP internal use means there is no
point of DS-lite to save public IPv4 addresses for ISP internal
use. ISPs can internally use IPv4 addresses forever, even after
public IPv4 addresses are exhausted.

If we have enough IPv4 addresses for customers but not for ISP
internal routers, we can still enjoy traditional IPv4 networking
without port restriction.

If we don't, with port restriction, we can still enjoy traditional
IPv4 networking without any real problem.

						Masataka Ohta

---

From: Dave Thaler <[email-masked]>
Date: Thu, 19 Nov 2009 22:03:05 +0000

The slides intentionally didn't mention specific proposals since they
vary and the slides concentrate on summarizing the issues _in general_
with the notion of "port-restricted IPs", that have been raised by 
various people on various lists and in various discussions, but were
not all in one place.

Several people have requested it be turned into an Internet Draft to
make points easier to discuss, and I am willing to help do so.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Rémi Després
> Sent: Wednesday, November 18, 2009 5:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [shara] "Issues in Port-Restricted IPs" and SAM.A+P
> 
> Hi all,
> 
> - True, an IPv4 address part of a SAM.A+P locator departs somewhat from
> the classical IP-address model: instead of being the address of one and
> only one interface, it is only used in combination with a port prefix,
> and then identifies a pseudo-interface (as defined for
> 6to4 in RFC 3056).
> - Note that ND-proxies introduce a different extension of the IP model,
> without this being a big issue: several interfaces, on different links,
> advertise the same address as being theirs.
> It provides additional connectivity, but only to hosts that support it.
> (Support is backward compatible, and deployment is incremental).
> 
> This limitation, due to the IPv4 address shortage per se, is common to
> all address sharing schemes.
> 
> error messages (which are the important ones in classical applications
> across the Internet, in particular for MTU determination.
> 
> - To encapsulate A+P packets, a SAM.A+P host has always, in addition to
> its shared IPv4 address, an interior address in a different address
> family (typically IPv6). "Pure A+Ps" therefore don't exist.
> - SAM.A+P, which needs only a new DHCPv6 option, is neither complex nor
> costly.
> - Training and education on SAM.A+P is marginal if combined with those
> on CGNs. (Port-prefix extension of addresses, and stateless address
> mappings and encapsulations, that are already familiar with 6to4, are
> simple concepts; on the other hand, CGNs issues include endpoint
> independent vs dependent mappings, hair-pinning, various ALGs, dynamic
> port reservations with UPnP and/or NAT-PMP, port- reservation limits to
> avoid DOS attacks, which are much less simple
> matters.)
> 
> queries go to the CGN (precisely to have better port randomization, and
> thus mitigate the danger of Kaminsky attacks).
> - For maximum security, IPv6 should to be used, in particular to reach
> DNS servers.
> 
> - The fact that some people may propose to misuse a new useful new tool
> shouldn't prevent this tool to be available for its normal purpose.

---

From: <[email-masked]>
Date: Fri, 20 Nov 2009 08:06:11 +0100

This effort will really help, and it will be the opportunity to launch an open discussion on the subject.

Pierre 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dave Thaler
Envoyé : jeudi 19 novembre 2009 23:03
À : [email-masked]; [email-masked]
Objet : Re: [shara] "Issues in Port-Restricted IPs" and SAM.A+P

-Dave

> scenarios where they are the less harmful.

_______________________________________________
shara mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/shara

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Nov 2009 12:33:29 -0800 (PST)

Hi Dave,
  After the meeting I talked to Dan. Our conclusion was what you mentioned below, please publish your slides in draft format. In IETF we can do drafts, and drafts only :).

Regards,

Behcet

----- Original Message ----
> From: Dave Thaler <[email-masked]>
> To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Thu, November 19, 2009 4:03:05 PM
> Subject: Re: [shara] "Issues in Port-Restricted IPs" and SAM.A+P
>