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

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

Le 19 nov. 09 à 11:05, Masataka Ohta a écrit :

> Remi Despres wrote:
>
>> At the aplusp BOF, Dave Thaler presented a list of "issues in port
>> restricted IPs".
>
> 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.

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.

> Do you have some? I have none.
>
>> Imposed by the scope of the BOF, strictly limited to A+P for DS-lite,
>
> DS-lite?

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

> 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.

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

Regards,
RD

---

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,
> 
> 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: <[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: 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 19:05:03 +0900

DS-lite?

						Masataka Ohta

---

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: 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: 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
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 23 Nov 2009 18:06:20 +0100

Retransmission to Softwire.
(The original, successfully transmitted to the Shara list but too big for the Softwire list, has been reduced here by replacing a .doc attachment by a .txt .)
RD

> De : Rémi Després <[email-masked]>
> Date : 18 novembre 2009 14:52:23 HNEC
> À : [email-masked]
> Cc : [email-masked]
> Objet : "Issues in Port-Restricted IPs" and SAM.A+P
> 
> 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.
> 
> - 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.
> - 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.
> 
> It provides additional connectivity, but only to hosts that support it. (Support is backward compatible, and deployment is incremental).
> 
> - When customer sites can no longer have exclusive IPv4 addresses, no application may rely on having any specific port.
> 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.
> 
> - The problem of incoming PINGs, and of other port-less protocols, is common to all address sharing schemes.
> - 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.
> 
> - 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.
> 
> - 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.
> 
> - 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.)
> 
> - 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.
> 
> - 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.
> 
> 
> - 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
> 
>