Re: [OPSAWG] [v6ops] Heads up - Plea for allocating a /8 to ISPs

Jason,

	The issue is that the operators using this block would NOT leak 5.x.x.x/8 out of their network, so it's routable on THEIR backbone, but not the broader network.  In fact, the CPE would see it, but nothing else should.  There should be no 5.x.x.x/8 visible from any customer network, other than the CPE.

	Chris

On 12Nov2010, at 04.15, Jason Lin wrote:

> Victor,
> 
> Yes, I miss the important constrain "in some case". :)
> 
> Actually, I'm worry about the situation like this:
> (Assuming the new reserved space is 5.x.x.x/8)
> 
> Currently: (in some case)
> 
>          /---------------------------\
>        <    ISP Backbone      >    non-RFC1918 can be routed in backbone,
> so it includes 5.x,x,x/8
>          \--------------------------/
>            /                       \
> [  MAN 1 ]       ...    [ MAN X]       RFC1918 may be routed in some MAN
> 
> 
> Cheers!
> 
> Jin Yan Lin
> China Telecom
> 
> On Fri, Nov 12, 2010 at 12:41 AM, Victor Kuarsingh <
> [email protected]> wrote:
> 
>> Jason,
>> 
>> I would have to disagree with that position.  In our case, it would be
>> exactly the opposite.  The non-RFC1918 block would replace public addresses,
>> therefore the same class of security policy applies.
>> 
>> Using RFC1918 (other then the other technical reasons given as to what it’s
>> problematic) would require more uplifts of security polices, ACLs, and
>> network related configuration.
>> 
>> I think the points is it is provider by provider dependant.  If the provide
>> historically used RFC1918 for addressing, then perhaps in that case it would
>> be as you said, but this is definitely not true for providers that current
>> supply public space to endpoints (until we run out of course).
>> 
>> Regards,
>> 
>> Victor
>> 
>> 
>> 
>> On 12/11/10 12:24 AM, "Jason Lin" <[email protected]> wrote:
>> 
>> hi,
>> 
>> Considering currently security policies that have been deployed in the
>> network, the new reserved /8 prefix may lead to not only re-design the
>> security policies, but also reconfigure the related nodes which has high
>> risk.
>> 
>> so, my point is negative.
>> 
>> Jin Yan Lin
>> China Telecom
>> 
>> 
>> On Fri, Nov 12, 2010 at 12:15 AM, Gert Doering <[email protected]> wrote:
>> 
>> Hi,
>> 
>> On Thu, Nov 11, 2010 at 04:18:49PM +0800, Rémi Després wrote:
>>> But you won't be hurt if some others use this new /8 prefix.
>> 
>> Sure.  Someone else might have a good use for a /22 that they can't
>> get because the last /8 was taken away for NAT444 services.
>> 
>> Especially content providers will need small bits of IPv4 space to
>> provide content to large masses of not-yet-IPv6 capable eyeballs.
>> 
>> Against this proposal.
>> 
>> Gert Doering
>>        -- NetMaster
>> --
>> did you enable 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
>> _______________________________________________
>> v6ops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> 
>> ------------------------------
>> _______________________________________________
>> v6ops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
> _______________________________________________
> OPSAWG mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsawg

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area