North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: ULA BoF

  • From: Fred Baker
  • Date: Fri Jun 01 19:30:06 2007
  • Authentication-results: sj-dkim-4; [email protected]; dkim=pass (si g from cisco.com/sjdkim4002 verified; );
  • Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=752; t=1180740459; x=1181604459; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; [email protected]; z=From:=20Fred=20Baker=20<[email protected]> |Subject:=20Re=3A=20ULA=20BoF |Sender:=20; bh=VMAFbT+XnO0kgkHDlQHKVnnVSCEy6fWYOlaiw1unyOU=; b=JouKyDZgLlJX14ebxSL0q/8mWBP9azRlrqu9KjO30WRkCI9IUq6oDOa4eXGcZKGRmvfWTzlm R25EKr2wYykgWIBYc+Jsi9xgj5C16EeWZjSU9s00RLYDCXi784lNEvn3;


On Jun 1, 2007, at 4:05 PM, Iljitsch van Beijnum wrote:

Solution: new type of local addresses that doesn't require any router magic to keep the packets within the site, and is globally unique so network merging isn't an issue.

But ULAs *do* require router magic. They require a policy to be in place that causes them to not be advertised unless the policy is overridden, and a policy that doesn't believe them even if they are mistakenly advertised. The simple way to accomplish this is to either (small installations) list the prefixes one will advertise or accept, or (larger installations) explicitly deny ULAs before permitting those in the relevant communities (send side) or accepting anything received.