Re: [Softwires] [BEHAVE] Stateless Address Mappings (SAMs) - new draft

[Rémi Després <[e-mail]>]

Dave,

Thanks for your detailed comments, and for the useful pointers to relevant RFCs and I-Ds.

More comments below.

Regards,

RD


Dave Thaler   (1-12/1-31/200x) 11/5/08 9:47 PM:

I have read this draft.  In my opinion, it is within the scope of Softwires
but may be of interest to some Behave folks.  The only real part I can see
that might be within the scope of Behave is section 3.6 where it discusses
scrambling IPv6 addresses as packets flow through a SAM.

Yes, section 3.6 is clearly in the scope of Behave.

IMU, this is also the case for section 3.2.3 on  the port-prefix based extended IPv4 addresses: it concerns "Division of port space to share one IPv4 addresses among multiple endpoints at the same time", which Magnus Westerlund announced to be in Behave's scope (e-mail attached).

  I'd suggest this
be separated into its own draft since it's largely orthogonal to the rest
of the document (which is more about encapsulation, not translation).
  

As this has strong relationship with Margaret's NAT66 draft, trying to regroup the contents could  IMHO make sense, but to be discussed more.

Technical comments:

1) The draft doesn't say what will break and probably should (ping,
   well-known ports, etc).  Some of the same problems that occur with
   multilink subnets (RFC 4903) occur in this proposal too, since
   not everything will be aware that the "subnet" isn't an IP prefix.
   Similarly, the required Subnet-Router Anycast addresses (RFC
   4291 section 2.6.1) may not work correctly.
  

- With  extended IPv4 addresses, pings are indeed impossible (like across NATs or any address sharing mechanism).
- I agree that a sentence on it is appropriate (I even had one at some stage, but lost it later on.)

- Whether a problem related to multilink subnets does appear with the proposal is still unclear to me.
- It seems unnecessary that "everything" be aware that a subnet IT is longer than 64 to keep the rule of only one link per subnet. Note that in 3.2.3 the mentioned prefix is that of a "subnetwork", not that of a "subnet" as defined for IPv6.  Instead of "subnetwork", "local routing domain" should be better .

2) The draft assumes that the first fragment always arrives first.
   As discussed in draft-iab-ip-model-evolution-01.txt section 3.1.7,
   this is not a safe assumption today.
  

- I tried not to  assume completely that it was that way, but I agree that the point should be developped.
- Would you have details on a real case where a provider  routinely disorders packets having same source and same destination (the only case of concern here). IMU, this would be _very bad_ for many TCP implementations.

3) The use of the "u" bit in IIDs seems problematic for several reasons.
   One, it only applies to IPv6 addresses that don't start with binary 000.
  

Right, the next version should clarify that what is said about the "u" bit  only applies to addresses that don't start with 000.

   Two, the semantics of the bit defined in RFC 4291 have to do with
   making it easy to configure non-conflicting addresses, and are not
   about privacy demands; overloading this bit for a second purpose
   seems problematic.
  

Right. Saying it as I did in section 3.6 is a bug. Thanks for seeing it.

Actually,  the SAM privacy protection  should rather be applicable only to v6E addresses. The level of privacy achieved with the SAA privacy extension of RFC 4941 would then stands for itself in global addresses.

4) Regarding the IPv6 address scrambling in section 3.6, not defining
   the scrambling (or at least not providing requirements for it) would be
   problematic in two regards.  1) If you allow asymmetric paths then
   you need the same algorithm in each SAM at the edge of your network;
   2) some implementations may pick a weak method that allows an
   outsider to guess the algorithm.
  

Yes, all external edge SAMs must obviously have the same scrambling method.
At least for this reason, standardizing a default scrambling is useful, I agree (coexistence of edge SAMs from different suppliers etc.)

It remains that vendors may propose, as options, whatever scrambling method they feel may be better .

Comments inline (along with a bunch of editorial nits) in PDF attached.

-Dave

  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Rémi Després
Sent: Wednesday, November 05, 2008 8:46 AM
To: Softwires WG; Behave WG
Cc: [e-mail]
Subject: [BEHAVE] Stateless Address Mappings (SAMs) - new draft

The new draft on SAMs is at
http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt" rel="nofollow">http://www.ietf.org/internet-drafts/draft-despres-sam-01.txt.

It deal with global connectivity, in IPv4, IPv6,  and extended IPv4,
across local domains where routing is different.

- Its automatic tunneling aspects are in the new scope of Softwires
- Its IPv4 address extension aspects, based on dynamic-port prefixes,
are in the scope of Behave.

Regards
RD

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave" rel="nofollow">https://www.ietf.org/mailman/listinfo/behave
    

--- Begin Message ---

IETF Community,

There has been a lot of activity on the topic of improving IPv4 and IPv6
coexistence, deployment of IPv6, and coping with the increasing shortage
of unassigned IPv4 addresses. This work crosses a number of layer and
area boundaries, which has led to new lists, cross-posting, etc. In
order to limit confusion, we'd like to give some guidance on where
to discuss what on which lists. The intent is not to declare any work
as in or out of charter with this message, only to try and direct list
discussion. These are only general guidelines, so please don't be
alarmed if we missed something in particular. Our hope is that this will
help everyone to continue the rich dialog on this important topic.

1. [e-mail]

Softwires is chartered to work on combinations of IPv4/IPv6 and
IPv6/IPv4, including "dual-stack lite" functionality. This includes
discussion related to:

- All types of IPv4/IPv6 tunnels, including encapsulation, control
  plane, etc.
- Affects of tunnel endpoints terminating into a concentrator performing
  IPv4 to IPv4 NAT
- Discovery of tunnel endpoints
- Tunnels initiated by hosts or gateways
- Tunnels automatically setup by routing and special prefixes

Thus, if it involves a tunnel or encapsulation of IPvX over IPvY,
softwires is the place to go.

2. [e-mail]

The Behave WG is currently being rechartered. If the new charter is
approved, behave will work on various types of IPv4<->IPv6 translation.
Please direct all discussion related to:

- IPv4 to IPv6 and IPv6 to IPv4 translation
- IPv6 to IPv6 NAT
- Division of port space to share one IPv4 addresses among multiple
  endpoints at the same time
- Affects on applications and transport protocols
- ALGs
- IPv4 to IPv4 NAT functionality, including for ISP deployments

Thus, if discussion involves an IP translator or the internal function
of a NAT, behave is the place to go.

3. [e-mail]

- Operational discussions on the topic of coexistence in general
- IPv6-only deployment

Thus, if it involves operational issues of IPv6 or IPv4 exhaustion, go
to v6ops.

4. The [e-mail] list will be removed after the Minneapolis
IETF meeting.


Jari Arkko
Ron Bonica
Lars Eggert
Mark Townsley
Magnus Westerlund


Resources:

WGs
Behave: http://www.ietf.org/html.charters/behave-charter.html
Softwire: http://www.ietf.org/html.charters/softwire-charter.html
v6ops: http://www.ietf.org/html.charters/v6ops-charter.html

_______________________________________________
v4v6interim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v4v6interim

--- End Message ---

_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires