Subject: about draft-ietf-v6ops-cpe-simple-security-07

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 16:01:11 +0200

[to v6ops and shim6, prune as necessary]

    R11: Filter state records for generic upper-layer transport  
protocols
    MUST NOT be deleted or recycled until an idle timer not less than  
two
    minutes has expired without having forwarded a packet matching the
    state in some configurable amount of time.  By DEFAULT, the idle
    timer for such state records is five minutes.

That seems rather short: new transports would now have to send  
keepalives every 1.75 minutes. I'd say that a timeout MUST be at least  
11 minutes and preferably 124 minutes, like TCP.

If the timers for unknown transports are compatible with those needed  
for SCTP and DCCP then implementers can forego handling those  
explicitly but they'll still work.

3.2.4.  6to4 Tunnels

    Typical dual-stack IPv4/IPv6 residential gateways use private IPv4
    address ranges and network address/port translation on a single IPv4
    address assigned by the service provider.  The use of private
    addresses prevents interior hosts from using 6to4 [RFC3068] tunnels.

Usually the private addresses are on the inside and a public on the  
outside (which will presumably start to change as IPv4 depletes but  
will never completely go away) so 6to4 can work just fine in those  
cases.

    The use of Level 3 Multihoming Shim
    Protocol for IPv6 (SHIM6) [I-D.ietf-shim6-proto] as a site multi-
    homing solution is not generally compatible with IPv6 simple
    security.

(Now RFC 5533.) Why? Assuming that there are two CPEs with each an ISP  
link and advertising separate address ranges, then if the host sends  
normal packets over CPE A and then when the ISP connected to CPE A  
fails, the host can send protocol 140 signaling and encapsulated data  
packets to CPE B. This should work. An optimization would be to allow  
incoming protocol 140 whenever there is communication between an  
internal and external host already, whatever the type. (Without that,  
the shim6 signaling fails when the first host initiates it and only  
succeeds if the second host initiates it soon enough after.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 28 Jul 2009 16:16:26 +0200

Another thing:

If the CPE subdelegates a prefix to another CPE, it shouldn't filter  
anything except martians towards the delegated prefix routed to the  
other CPE.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Jul 2009 11:00:43 +1200

> [to v6ops and shim6, prune as necessary]

Pruned to v6ops

...

> outside (which will presumably start to change as IPv4 depletes but will
> never completely go away) so 6to4 can work just fine in those cases.

Well, the text is unclear. If the hosts behind the CPE try to use
6to4 [RFC3056] tunnels (with or without the anycast extension [RFC3068]),
they will fail if the LAN is using RFC1918 and NAT. But if the CPE
itself acts as a 6to4 gateway as defined and intended in [RFC3056],
the hosts will see *native* IPv6 and everything will work fine.
Except for one case:

     The use of private addresses by an ISP "outside" the CPE
     would mske it impossible for the CPE to operate
     as a 6to4 [RFC3056] gateway.

IMHO every IPv6 CPE SHOULD contain a 6to4 gateway, but that belongs
in another draft.

    Brian

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Jul 2009 09:58:15 +0200

> IMHO every IPv6 CPE SHOULD contain a 6to4 gateway, but that belongs  

I'd argue that's a topic for the HOMEGATE effort.  A Teredo relay  
might help too.

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