Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice

From: Wuyts Carl <[email-masked]>
Date: Wed, 5 Sep 2012 09:53:05 +0200

Hi Marc,

I'm working in the CPE area, supporting ULA-usage.

ULA indeed to be used for "internal" traffic only, this can also be traffic over VPN within your company. I don't see why you drag NAT along, there's no relation to NAT using ULA.  I assume you make this link based upon private addressing in IPv4 and its NAT appliance.

A CPE typically uses a default route, hence the ULA-packet indeed will be dropped when destined to "the internet".

There's no problem assigning ULA next to GUA address(es); this can be done manual or just using the RTADV daemon of the CPE.

Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Lampo
Sent: vrijdag 24 augustus 2012 13:16
To: [email-masked]
Subject: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice

Hello group,

now read and reread both RFC's, but I feel not everything is said with respect to ULA.
Please clarify, suggest, advice considering the following :
- 6092, REC-7 states :
  "by default, packets with ULA source ... should not be forwarded to ... exterior network."

- 6204 recommends customer edge routers implement 6092
  (in 4.4, Security Requirement #1)
  --> (implied) customer edge routers should not forward ULA sources to the Internet.

- 6204 also recommends the use of ULA, internally !
  (cfr ULA-... requirements, and states (4.1 General Requirements)
   not to forward ULA over external inteface.)

So, how do I interpret this :
- ULA internally and NAT (network prefix rewriting) towards the external interface
  (which would satisfy the requirement of not forwarding ULA source IP over external interface)
  ((and which offers the benefit of ISP independancy for internal equipment)) or
- ULA is for communication between internal devices exclusively.
  A device that needs Internet connectivity must have public IP (and ULA for internal communication).
  --> is the (so far : static) address selection table capable of supporting this ?
       (I understand making address selection table configurable via
SLAAC/DHCPv6 are draft's only ?)
  ((and if I interpret address selection RFC correctly, preference to ULA would be given
    only if within the same /64 (if "label", in RFC3484 == /64). ))

Thanks for positive feedback on this !
Kind regards,

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Sep 2012 09:11:06 +0100

Carl,

I don't disagree with anything you say, but we shouldn't forget that some
people are pushing ULAs with prefix translation (draft-bonica-v6-multihome).
This is out of the scope of 6092, 6204 or 6204bis though.

I prefer draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat personally.

Regards
   Brian

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 5 Sep 2012 10:14:02 +0200

Ack.
Maybe I'm cutting too many corners here, but I'd say that anything without NAT is better in IPv6 :-).
Being operational mainly in residential (managed) gateways, multi-homing is usually not present, but should not be ignored of course.

Regs
Carl

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: woensdag 5 september 2012 10:11
To: Wuyts Carl
Cc: Marc Lampo; [email-masked]
Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice

Carl,

I don't disagree with anything you say, but we shouldn't forget that some people are pushing ULAs with prefix translation (draft-bonica-v6-multihome).
This is out of the scope of 6092, 6204 or 6204bis though.

Regards
   Brian

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Sep 2012 12:00:05 +0200

Hi,

> Being operational mainly in residential (managed) gateways, multi-homing is usually not present, but should not be ignored of course.

Assume that multihoming will be present before too long - "DSL plus Cable"
or "Cable + 3G" or whatever.  Two cheap contracts, in the hope that the
end result is more reliable than just one.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279