Subject: Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00

From: Ray Hunter <[email-masked]>
Date: Wed, 27 Jul 2011 22:14:46 +0200

Am I permitted to ask some dumb questions about this draft since it 
seems to be urgent?

The draft talks about translating IPv6 ICMPv6 responses back to a 
special shared /24 public IPv4 source range where responses are not 1:1 
IPv6 source - IPv4 source mappable (presumably because network links and 
equipment on the IPv6 side are using IPv6 space from outside the mapped 
range).

Don't we have this situation already when traversing multiple IPv4 
networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?

In that case doesn't ICMP just have to live with an RFC1918 source 
address, and no one seems to have complained too bitterly so far?

What's so special about this new IPv6 mapped situation that is different 
to the existing situation of overlapping RFC 1918 addresses used by 
multiple providers, where it's already unclear which unique node on the 
path generated the ICMP message, and where uRPF filters would already be 
an issue?

i.e. why should the ICMP messages just not be dropped in this case at 
the AS border, or be sent with RFC 1918 source addresses within an AS, 
or be sent using a source address from a globally unique (/24) sub-range 
of the existing provider IPv4 space assigned to the translator if they 
are so important?

I'm sorry, and maybe it's me being totally dumb, but I just don't see 
the added value of a "special" /24 shared amongst multiple providers, 
especially if there are possibly multiple translators and multiple 
providers on a path. It just doesn't seem to give any significant extra 
information to the intended recipient, and if anything may lead to more 
confusion. 128 into 32 doesn't go. End of story.

regards,
RayH

> Subject:
> [v6ops] Fwd: Request for WG Adoption of 
> draft-xli-v6ops-ivi-icmp-address-00
> From:
> Fred Baker <[email-masked]>
> Date:
> Wed, 27 Jul 2011 14:40:59 -0400
>
> To:
> IPv6 Operations <[email-masked]>
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1084)
> References:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset=us-ascii
> Message:
> 6
>
>
> Folks: the chairs are in receipt of this note. Please read the draft and comment.
>
> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.
>
> Begin forwarded message:
>
>    
>> >  From: Xing Li<[email-masked]>
>> >  Date: July 26, 2011 10:36:32 AM EDT
>> >  To:[email-masked]
>> >  Cc:[email-masked],[email-masked]
>> >  Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
>> >  
>> >  Hi V6ops Chairs,
>> >  
>> >  The authors of draft-xli-v6ops-ivi-icmp-address-00 would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
>> >  
>> >  The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
>> >  
>> >  The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
>> >  
>> >  regards,
>> >  
>> >  Xing Li
>> >  
>> >  
>> >  
>> >  
>>

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Jul 2011 17:35:22 -0400

On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote:

> Am I permitted to ask some dumb questions about this draft since it seems to be urgent?

Certainly. I will ask the authors to respond to them.

> The draft talks about translating IPv6 ICMPv6 responses back to a special shared /24 public IPv4 source range where responses are not 1:1 IPv6 source - IPv4 source mappable (presumably because network links and equipment on the IPv6 side are using IPv6 space from outside the mapped range).
> 
> Don't we have this situation already when traversing multiple IPv4 networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN links?
> 
> In that case doesn't ICMP just have to live with an RFC1918 source address, and no one seems to have complained too bitterly so far?
> 
> What's so special about this new IPv6 mapped situation that is different to the existing situation of overlapping RFC 1918 addresses used by multiple providers, where it's already unclear which unique node on the path generated the ICMP message, and where uRPF filters would already be an issue?
> 
> i.e. why should the ICMP messages just not be dropped in this case at the AS border, or be sent with RFC 1918 source addresses within an AS, or be sent using a source address from a globally unique (/24) sub-range of the existing provider IPv4 space assigned to the translator if they are so important?
> 
> I'm sorry, and maybe it's me being totally dumb, but I just don't see the added value of a "special" /24 shared amongst multiple providers, especially if there are possibly multiple translators and multiple providers on a path. It just doesn't seem to give any significant extra information to the intended recipient, and if anything may lead to more confusion. 128 into 32 doesn't go. End of story.
> 
> regards,
> RayH
> 
>> Subject: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
>> From: Fred Baker <[email-masked]>
>> Date: Wed, 27 Jul 2011 14:40:59 -0400
>> To: IPv6 Operations <[email-masked]>
>> Content-Transfer-Encoding: quoted-printable
>> Precedence: list
>> MIME-Version: 1.0 (Apple Message framework v1084)
>> References: <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=us-ascii
>> Message: 6
>>> > From: Xing Li <[email-masked]>
>>> > To: [email-masked]
>>> > Cc: [email-masked], [email-masked]

---

From: Ray Hunter <[email-masked]>
Date: Thu, 28 Jul 2011 04:52:49 +0200

The concern would be that the special /24 is creating a new range that:

- carries ICMP control messages, which could also be used to attempt to 
alter a senders' behavior
- is shared between multiple providers
- is not traceable
- should not be filtered at AS boundaries

which could grant an attacker a perfect set of source addresses for 
mounting a DDOS attack.

Yes the range isn't routable as a destination, but that possibly makes 
it even worse, as the target of any DDOS sourced from this range would 
have absolutely no idea who was sending them the huge volume of junk 
packets, except by incoming interface at the AS boundary. I see no 
reason why a network operator would want to accept such a packet from 
another AS into their network, so they'll basically get filtered 
everywhere after the very first attack IMHO.

regards,
RayH

Fred Baker wrote:
>> special shared /24 public IPv4 source range where responses are not 
>> 1:1 IPv6 source - IPv4 source mappable (presumably because network 
>> links and equipment on the IPv6 side are using IPv6 space from 
>> outside the mapped range).
>>
>> What's so special about this new IPv6 mapped situation that is 
>> different to the existing situation of overlapping RFC 1918 addresses 
>> used by multiple providers, where it's already unclear which unique 
>> node on the path generated the ICMP message, and where uRPF filters 
>> would already be an issue?
>>
>> the AS border, or be sent with RFC 1918 source addresses within an 
>> AS, or be sent using a source address from a globally unique (/24) 
>> sub-range of the existing provider IPv4 space assigned to the 
>> translator if they are so important?
>>
>> providers on a path. It just doesn't seem to give any significant 
>> extra information to the intended recipient, and if anything may lead 
>> to more confusion. 128 into 32 doesn't go. End of story.
>>
>> regards,
>> RayH
>>
>>> Subject:

---

From: Xing Li <[email-masked]>
Date: Fri, 29 Jul 2011 03:04:45 +0800

Hi, Ray,

Thanks for your mail. See inline.

? 2011/7/28 4:14, Ray Hunter ??:
> links and equipment on the IPv6 side are using IPv6 space from outside 
> the mapped range).
>

Yes,  using this special shared /24 will not introduce new problems 
compared with using RFC1918 space.

> or be sent using a source address from a globally unique (/24) 

Introducing a new well-known IPv4 block can help  to identify that the 
ICMP messages are actually translated from IPv6, which will make the 
management and trouble shooting easier.

> to more confusion. 128 into 32 doesn't go. End of story.

Regards,

xing

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

---

From: Xing Li <[email-masked]>
Date: Fri, 29 Jul 2011 03:13:30 +0800

Hi, Ray,

? 2011/7/28 10:52, Ray Hunter ??:
> - carries ICMP control messages, which could also be used to attempt 
> to alter a senders' behavior

When the special /24 is used, it can identify that the ICMP messages are 
generated in IPv6.
> everywhere after the very first attack IMHO.

As partially discussed in previous mail. This will not introduce new 
issues compared with using RFC1918 space. In Section 6 of this draft says

6.  Security Considerations

    The use of an address for source addresses in ICMP packets is
    considered "safe" in so far as ICMP packets are not intended to
    generate responses directed to the source address.

    However it is possible to use this address as a means of gaining
    anonymity when launching a denial of service attacks by using this
    address as the source address for other forms of malicious traffic.
    Packet firewall filters should be configured to treat addresses in
    the IANA-assigned /24 network as martian addresses by discarding all
    non-ICMP packets that use the IANA-assigned /24 network as a source
    address, and all packets that use the IANA-assigned /24 network as a
    destination address.

Regards,

xing

>>> different to the existing situation of overlapping RFC 1918 
>>> addresses used by multiple providers, where it's already unclear 
>>> which unique node on the path generated the ICMP message, and where 
>>> uRPF filters would already be an issue?
>>>
>>> i.e. why should the ICMP messages just not be dropped in this case 
>>> at the AS border, or be sent with RFC 1918 source addresses within 
>>> an AS, or be sent using a source address from a globally unique 
>>> (/24) sub-range of the existing provider IPv4 space assigned to the 
>>> I'm sorry, and maybe it's me being totally dumb, but I just don't 
>>> see the added value of a "special" /24 shared amongst multiple 
>>> providers, especially if there are possibly multiple translators and 
>>> multiple providers on a path. It just doesn't seem to give any 
>>> significant extra information to the intended recipient, and if 
>>> anything may lead to more confusion. 128 into 32 doesn't go. End of 
>>> story.
>>>
>>> regards,
>>> RayH
>>>
>>>> Subject:

---

From: Ray Hunter <[email-masked]>
Date: Thu, 28 Jul 2011 22:09:13 +0200

Following all IMVHO.

Sorry I'm not convinced. It isn't just packet firewalls that are going 
to need/want to drop these packets.

Imagine I'm acting as the responsible owner of an AS. Under this 
proposal I have all downside and no upside. Let me explain.....

If this range is going to be used for sourcing DDOS traffic (and I 
strongly suspect it will), and it isn't going to be possible to easily 
isolate or debug which upstream AS or site or network interface or 
customer device was the source of that bad traffic, then the packets 
need to get dropped at the AS border and every other uncontrolled entry 
point on the network that connects to third party managed devices. I 
don't want untraceable packets sourced by someone else floating around 
in my network and potentially causing trouble tickets / problems that 
cost my staff's and my management time.

Equally, if I'm acting as a responsible network operator, I don't want 
to act as a transit on a potential DDOS attack to other AS'es to avoid 
hurting my own good reputation (the downstream AS will have no idea if 
the DDOS attack originated in my AS, or another upstream AS, and my AS 
was just acting as a transit). Either way I'd look daft, and the DDOS 
attack would be difficult or impossible to trace: which is precisely one 
reason why ingress filters were recommended in the first place.

So all ingress and egress filters will probably end up dropping the new 
special range, and no one will be any the wiser.

In which case, using the special /24 shared range is actually less 
useful compared to just using a locally significant and existing  
RFC1918 range of addresses for each translator in my network for the 
translation of IMCPv6 messages sourced behind my own IPv6/IPv4 
translator(s) IMHO. At least then I and my staff would know exactly 
which translator the ICMP message came from in my AS if there was more 
than one translator present, and I'd be able to take corrective action 
if necessary.  Plus I'd know for certain if I saw such RFC1918 sourced 
ICMP traffic in my AS that they weren't sourced from someone else's 
translator in another AS that I don't even manage. And yes packets with 
RFC1918 source-addresses would also be dropped at the AS border, as today.

regards,
RayH

Xing Li wrote:
> When the special /24 is used, it can identify that the ICMP messages 
> are generated in IPv6.
>> Yes the range isn't routable as a destination, but that possibly 
>> makes it even worse, as the target of any DDOS sourced from this 
>> range would have absolutely no idea who was sending them the huge 
>> volume of junk packets, except by incoming interface at the AS 
>> boundary. I see no reason why a network operator would want to accept 
>> such a packet from another AS into their network, so they'll 
>> basically get filtered everywhere after the very first attack IMHO.
>
>>>> providers, especially if there are possibly multiple translators 
>>>> and multiple providers on a path. It just doesn't seem to give any

---

From: David Farmer <[email-masked]>
Date: Thu, 28 Jul 2011 20:40:30 -0500

On 7/28/11 14:13 CDT, Xing Li wrote:
> Hi, Ray,
>
> 于 2011/7/28 10:52, Ray Hunter 写道:

If this draft goes forward, beyond the above, I would like to see 
recommendations of both filtering to an appropriate list of ICMP types 
and probably an overall rate limiting of traffic from the prefix as 
additional countermeasure against abuse of this prefix.

Given the stated intended use I believe ICMP type 3 - Destination 
Unreachable,  ICMP type 11 - Time Exceeded, and maybe ICMP type 12 - 
Parameter Problem, and I'm not sure this last one is needed, are the 
only ICMP messages that SHOULD be allowed to be sourced from this 
prefix.  Additionally, this prefix SHOULD NOT be allowed to source any 
of the various ICMP request messages, as the response would necessarily 
have an destination address that is a martian address by even the 
current Security Considerations statement.

Ray is correct that this needs to apply not just to firewall filters but 
probably most AS border filters as well.  He is also correct, that many 
operators will just filter the prefix completely.

However, I see an advantage to assigning a well-known prefix in that it 
simplifies coordination of like minded operators allowing the 
appropriate ICMP messages to pass through their AS borders if they find 
it advantageous, even if many or most operators do not and block all 
packets sourced or destined to the prefix.  Trying to coordinate the use 
of an RFC 1918 prefix for this purpose across even a limited number of 
like minded operators is almost an impossible task.

Finally, some consideration for Reverse DNS for this prefix should be 
given.  This is probably one of the best arguments for assigning a 
well-known prefix, then some kind of human readable Reverse DNS can be 
provided, to help mortal Internet users when they traceroute through an 
IPv6/v4 translator.  This probably belongs in the IANA considerations 
section, or a separate section discussing Reverse DNS.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Ray Hunter <[email-masked]>
Date: Fri, 29 Jul 2011 09:46:41 +0200

David Farmer wrote:
>> <snip>
> of the various ICMP request messages, as the response would 
> necessarily have an destination address that is a martian address by 
> even the current Security Considerations statement.
>
Agreed. That was one of my concerns too. ICMP is a diverse (and growing) 
collection of types and codes. Not just Echo Reply or Time Exceeded.

Those same "unmappable" IPv6 routers and devices are also likely to 
initiate outbound traceroutes towards the IPv4 cloud. If you use RFC1918 
addresses, there's a good chance that you could make that outbound 
traceroute work too across the translator, at least within the AS. That 
probably won't work when using a shared special purpose address and more 
than one translator in the IPv4 AS.
>
> However, I see an advantage to assigning a well-known prefix in that 
> it simplifies coordination of like minded operators allowing the 
> appropriate ICMP messages to pass through their AS borders if they 
> find it advantageous, even if many or most operators do not and block 
> all packets sourced or destined to the prefix.  Trying to coordinate 
> the use of an RFC 1918 prefix for this purpose across even a limited 
> number of like minded operators is almost an impossible task.
>
Then they can use a publicly registered globally unique IPv4 address 
from one of their existing allocations that they agree to share across 
their group of AS'es. If it ever leaked out from their group of AS'es 
then at least it would be traceable back to one of the AS'es, who would 
then have to take responsibility for coordinating and solving any 
issues. No new standard required. But at least you'd have a problem 
owner to call.

Which will save the rest of the World from updating their ingress & 
egress filters, DNS reverse records, operations instructions, intrusion 
detection systems, possible end node implementations to ensure they 
don't try to reply to martian addresses.....
> provided, to help mortal Internet users when they traceroute through 
> an IPv6/v4 translator.  This probably belongs in the IANA 
> considerations section, or a separate section discussing Reverse DNS.

Can you think of any other example of a "one-way" special purpose packet 
that is allowed to leave the link, never mind the AS?

---

From: Xing Li <[email-masked]>
Date: Sat, 30 Jul 2011 22:12:10 +0800

? 2011/7/29 4:09, Ray Hunter ??:
> need to get dropped at the AS border and every other uncontrolled 
> entry point on the network that connects to third party managed 
> devices. I don't want untraceable packets sourced by someone else 
> floating around in my network and potentially causing trouble tickets 
> / problems that cost my staff's and my management time.
>
> attack would be difficult or impossible to trace: which is precisely 
> one reason why ingress filters were recommended in the first place.
>
> So all ingress and egress filters will probably end up dropping the 
> new special range, and no one will be any the wiser.
>
> translator in another AS that I don't even manage. And yes packets 
> with RFC1918 source-addresses would also be dropped at the AS border, 
> as today.

Actually they are the configuration choices
(1)    If the network owner of the translator(s) has enough public IPv4 
address, he/she can configure the translator(s) using the public IPv4 
for it. However, for many networks, they cannot afford to do so due to 
the IPv4 address depletion.
(2)    The network owner can use RFC1918 for this. However, if the 
network has already use RFC1918 addresses, careful network plan is 
needed. In addition, this cannot be used to identify the IPv4/IPv6 
translation.
(3)    The special /24 can be thought as a "new block of RFC1918" in 
this sense, i.e. the routing behavior is similar. However, this block is 
targeting the IPv4/IPv6 translation, and can be configured specifically 
for it. This provides more control for the network administrator. The 
drawback for this method is that the network administrators needs to 
update the acl list for this special block. However, we believe it is 
worth the effort for the transition.

For your reference, there were some discussions in the earlier version 
of this draft, see  
http://tools.ietf.org/html/draft-xli-behave-icmp-address-02 If people 
think we need more discussion like this, we can put the discussion in 
the appendix of this document.

Regards,

xing

>>> boundary. I see no reason why a network operator would want to 
>>> accept such a packet from another AS into their network, so they'll 
>>>>> special shared /24 public IPv4 source range where responses are 
>>>>> not 1:1 IPv6 source - IPv4 source mappable (presumably because 
>>>>> network links and equipment on the IPv6 side are using IPv6 space 
>>>>> from outside the mapped range).
>>>>>
>>>>> which unique node on the path generated the ICMP message, and 
>>>>> where uRPF filters would already be an issue?
>>>>>
>>>>> (/24) sub-range of the existing provider IPv4 space assigned to 
>>>>> the translator if they are so important?
>>>>>
>>>>> anything may lead to more confusion. 128 into 32 doesn't go. End 
>>>>> of story.
>>>>>
>>>>> regards,
>>>>> RayH
>>>>>
>>>>>> Subject:

---

From: Xing Li <[email-masked]>
Date: Sat, 30 Jul 2011 22:16:48 +0800

Hi, David,

> even the current Security Considerations statement.

Thanks, we can add the recommendations for acl and rate limiting for 
this special /24 in the document.

> Ray is correct that this needs to apply not just to firewall filters 
> but probably most AS border filters as well.  He is also correct, that 
> many operators will just filter the prefix completely.
>

Agree. The special /24 is well defined and can be make the life of the 
operators easier.

> considerations section, or a separate section discussing Reverse DNS.

Agree. We will try add this section. Thanks.

Regards,

xing