Subject: (ngtrans) forwarding SHIPWORM for PS

From: Bob Fink <[email-masked]>
Date: Thu, 18 Oct 2001 18:39:50 -0700

Randy,

SHIPWORM-02 finished ngtrans WG last call with comments that were resolved 
in the new -03 draft:

<http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-03.txt>

Please process this draft as a candidate for PS.

Thanks,

Bob

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 Oct 2001 23:11:40 -0700

> Please process this draft as a candidate for PS.

the iab has raised a general architectural issue regarding nat traversal
that has clear relevance to this draft, midcom, and so forth.  i am trying
to understand it more before progressing.  please stay tuned.

randy

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Oct 2001 11:11:36 +0300 (EEST)

snipping cc: a bit.

> to understand it more before progressing.  please stay tuned.

FWIW,

I see two big issues that may concern some people with these:

 1) philosophical: how far should we try to work around difficulties of 
NAT's.  When should we figure it's time to give up to save the pain in the 
end, and conserve work resources.

 2) technical: real measurements on how stable these "pass-through"
connections through various NAT's really are.  "how does it work through 
MY nat?"  That is, does this work well enough in practise?

As for 1), in general it may be that several groups (e.g. midcom) are
going too far.  But as IPv6 is one of the solutions for these problems,
and if 2) works, Shipworm could perhaps be viewed as an exception.

As for 2), I'd be interested if someone has implemented e.g. a simple
client/server program which could be run on both sides of the NAT to
measure how stable the mappings are.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Oct 2001 17:13:11 +0200

As an IABer... some of us see a significant difference between Shipworm
and some of the ideas being discussed in Midcom... I will certainly
not be trying to block Shipworm via the IAB, quite the opposite. But
it does make people a bit nervous.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org

---

From: Keith Moore <[email-masked]>
Date: Fri, 19 Oct 2001 12:40:39 -0400

> and some of the ideas being discussed in Midcom

I sincerely hope that IAB isn't endorsing midcom as an architectural 
direction.  

Keith

---

From: "Eng Soo Guan" <[email-masked]>
Date: Tue, 23 Oct 2001 10:51:41 +0800

Dear All,

May I know that for Shipworm IPv6 addresses, what are the concerns relating
to putting the 48 bit of IPv4 address and UDP port as part of the Node ID
instead? I think there will be less problems relating to filtering
(especially connecting to 6Bone) than putting them immediately after the
first 16 bits of a IPv6 address.

Warmest regards.

SG
Soo Guan, Eng
Centre for Wireless Communications, NUS
http://www.cwc.nus.edu.sg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Oct 2001 00:22:44 +0300 (EEST)

> first 16 bits of a IPv6 address.

There are many reasons; this is in line with "6to4".  You're probably
thinking of ISATAP-like approach, but that is used for p-t-p tunneling;  
not addressing entire subnets behind ISATAP routers.

There can be a lot of Shipworm clients (i.e. dummy IPv6 nodes) behind 
routers: that is e.g. with address 2003:aabb:ccdd:1111:x:y:z:w, where 
x:y:z:w are derived from the MAC addresses.  If the embedded address would 
be placed there, how could these be distinguishable?

As the 48 bits of IPv4 + UDP are strictly after the 16-bit TLA, you can 
actually set routes which have sane prefix lengths with these addresses; 
that is, (internally) you could add route for:

2003:1122:33::/40, "to get an IPv4 C-class of NAT's", instead of:
2003::1122:3300:0/104

Also note the typographical ease of the first writing method.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Oct 2001 14:56:19 +0300 (EEST)

On Thu, 25 Oct 2001, Eng Soo Guan wrote:
> Why do we need x:y:z:w? That is my doubt. For example, regular IPv6 routing
> only needs 2003:aabb:ccdd to get the packet to the Shipworm Client behind
> the NAT. Or did I miss something else (e.g. security)?

End-to-end connectivity.

You're confusing IPv4 and IPv6.

IPv6 nodes behind the Shipworm clients must have x:y:z:w, else the 
Shipworm client would have to perform IPv6 NAT.  And we don't want that.

> I agree that it is easy to write 2003:1122:33::/40. However, in the spirit
> of true Shipworm 'stateless'-ness (*smile*), then we should have less human
> interventation to add routes. Also, I think adding routes as such gives 2
> issues.

Routes are only one example, firewall access lists or shipworm 
server/relay "allowed clients" lists additional ones.
 
> (1) Does Shipworm Server knows WHEN to add the entry for a particular NAT?
> Should it do so whenever it receives a RS from a new IPv4 destination?
> Should there be a lifetime for each entry?

I believe these should be addressed in section 4.3.

> (2) For the IPv6 Router directly connected to a Shipworm Server, should it
> perform ingress filtering with addresses starting with 2003:? In other
> words, should it allow ALL traffic from sources with Shipworm Prefix?

AFAICS, that is not required.

If the Server serves only e.g. internal NAT's or some closed domain, so
that you know exactly which IPv4 addresses everybody you advertise the
shipworm IPv4 anycast address to use, you could perform stricter
filtering too.

---

From: "Eng Soo Guan" <[email-masked]>
Date: Thu, 25 Oct 2001 13:27:33 +0800

> not addressing entire subnets behind ISATAP routers.

Actually, I am also thinking about addressing entire subnet, not
point-to-point tunneling.

Soo Guan, Eng
Centre for Wireless Communications